* Modified tmk_core/rules.mk to avoid linking errors
Added -fcommon flag to avoid linking errors due to multiple variable definitions. Though this is neither a definitive nor good solution, proper changes and use of extern keyword to avoid those multiple definitions must be made
* Comment updated
* [Keyboard] spiderisland/split78: add MCP23018 reset code
Now, communication with the right side gets re-established
after unplugging it and plugging it back in.
* [Keyboard] spiderisland/split78: configure debouncing
I've been experiencing particularly bad bounce on the 'A' key.
Also, update maintainer github username
* concatenate config.h to 64key directory
* move rules.mk to 64key directory
This commit makes the firmware actually compile.
* insert complete rules.mk contents
Conforms the file to QMK's template.
* move info.json to 64key directory
* remove concertina.h
This file no longer serves a purpose now that everything is in the 64key directory.
* complete 64key readme.md
Conforms the file more to QMK's template.
* VEA Support
* Update LEDs to use QMK methods
* Enable Backlight
* Update Vendor ID
* Updates to enable split RGB
* Update readme
* Update to split RGB
* remove unnecessary reference
* Knight animation starts at the back
* remove hardcoded variable
Co-authored-by: Major Koos <MajorKoos@noreply.users.github.com>
* [Keyboard] Add 'LAYOUT_65_ansi_split_bs' support to KBDfans KBD67 rev2
This is already supported by VIA.
* [Keymap] Fix kbd67 catrielmuller_camilad keymap
* [Keyboard] Add my keymap for KBDfans KBD67 rev2 using 'LAYOUT_65_ansi_split_bs'
* Create Alter folder
* Revert "Create Alter folder"
This reverts commit 361103b821.
* Added n60_s folder
* Fixed the url of the image in the readme
* Updated readme
* Updated readme
* Updated readme
* Added new section to docs: Checking Modifier State
* Added id anchors to all headers in modifiers docs
* Added a Wikipedia link to bitwise operators and...
crosslinked to the QMK macro docs.
* Added an explanation on the format of mod bitmask
* Added .md extension to hyperlinks to macros docs
* Corrected mod mask order and changed notation
* Documented add_oneshot_mods and del_oneshot_mods
* Mentioned modifier checks in the macro docs
* Explained strict modifier checking
i.e. using `get_mods() & MOD_MASK == MOD_MASK` instead of simply
`get_mods() & MOD_MASK`
* Added (un)register_mods to the docs
* Put left term of comparison in parens
* initial rgb driver fix
* added underglow LEDs and fixed typo in RGB locations
* removed test code
* added my key maps
* updated rgb keymap to work with changes
* refactored my code to make it more maintainable and updated keymaps.
* added GPL licence
* add podman support to docker_build.sh script
* break out runtime into the RUNTIME variable
* allows RUNTIME to be set by the user
* decides on docker or podman if docker isn't avaible
* rewrote check for docker-machine to account only for docker runtime
* put --user arg into a variable only to be used with docker
this is not needed with podman as podman maps the containers root id
to the users id.
* add podman to getting_started_docker documentation
* Add suggestion for indirect unicode input on Linux
I have used this approach myself with great success, and it seems to be the only good solution that doesn't involve IBus.
* Elaborate on keyboard layout on Linux
This should be enough to allow people to figure out how to add custom characters to a Linux keyboard layout.
* restore main readme.md
* add ChangeLog entry for 2021-02-27 develop branch - initial version
* update Docs; consolidate sidebar entries to new Breaking Changes History doc
* Changelog update
- concatenate similar changes as one list item
- unify change formatting (remove [bracketed] headings and trailing periods)
- item sorting improvement
* update Changes Requiring User Action section
Detail the changes regarding keyboard relocations/additions/deletions.
* add entry for fauxpark's user keymap cleanup for config.h/rules.mk
* add link to Jacky Studio bugfix PR
* add link for "ChibiOS conf migrations... take 15"
* add links for "Make LAYOUT parsing more robust" and "Massdrop develop rgb fix"
* remove sort sequence numbers
* rename Breaking Changes History page
Renames the Breaking Changes History page to "Past Breaking Changes".
* update schedule in Breaking Changes Overview
* suggestions/changes per tzarc
* skully's changes
* add entry for "Fix develop" (PR 12039)
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Zach White <skullydazed@gmail.com>
Fixes file encoding errors on Windows, and layouts not correctly merging into info.json.
* force utf8 encoding
* correctly merge layouts and layout aliases
* show what aliases point to
PR 10528 was intended to move the source for the Bear 65 and S7 Elephant to the new `jacky_studio` vendor directory. Instead of moving the source files, that PR added the source as if they were newly-supported. The result is that the Bear 65 and both revisions of the S7 Elephant have working, identical firmware in two different directories.
This commit removes the source from the old directories.
* tmk_core/common/report.h: define `enum mouse_buttons` in terms of `#define MOUSE_BTN_MASK()`
* tmk_core/common/action.c: collapse multiple `case KC_MS_BTN[1-8]:` into single `MOUSE_BTN_MASK(action.key.code - KC_MS_BTN1)`
We all love tapping on our keyboards but this is taking the piss.
This saves ~134 bytes on my ATmega32.
ANAVI Macro Pad 2 is an open source mini mechanical keyboard with
2 keys and backlit. Powered by ATtiny 85 microcontroller and with
microUSB connector. Designed with KiCad.
Provides the following keymaps for ANAVI Macro Pad 2:
- Default (with a, b and combo to control the LEDs)
- Copy & paste
- Tap dance example with a, b and c
- Mute
- Volume
- Zoom
- Jitsi Meet
Co-authored-by: Drashna Jaelre <drashna@live.com>
Signed-off-by: Leon Anavi <leon@anavi.org>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Latam version of Helix/rev2/back
. Latam adaptation of keymap(whit "ñ")
. 3 layers (Qwerty, Lower, Raise)
. Underglow light changes while pressing Lower(BLUE) and Raise(RED), then it returns to prior mode.
(cherry picked from commit 974be350115b2d33b55edbc02e3b5281e1f856d7)
* Se añade Keymap.
* Agrego un pdf preliminar del mapeo y reubico el keymap a carpeta correspondiente.
* Ajustes en mapeo para simplificar.
Agrego Mark Down con mapeo.
Creo carpeta "layers mapping" para guardar lo correspondiente a mapeo.
* Update keymap.md
* Rename keymap.md to readme.md
* Organización en general y cambio de configuración de "back" a "under"(que era la que correspondía).
.Ahora los leds underglow responden mejor.
* -Se agrega indicador rgb para el bloq mayús.
-Se agrega manejo del rgb_tog.
-Se agrega botón para reset(del teclado).
-Ajustes de keymap varios.
-Limpieza de código.
* Update readme.md
* Update readme.md
* Update readme.md
* adding helix-keyboard.png
* Update readme.md
* -Se agregan Mouse Keys (para manejo del mouse con el teclado).
-Se hace fix en el modo "Bloq. Mayús" (Se persiste el cambio de RGB mode mientras el Bloq. Mayús está activado).
* Cambios en el Keymap para mayor comodidad del uso del mouse.
* Update readme.md
* Update readme.md
* -Fixeo de comportamiento del "Bloq. Mayús":
Cuando se presionaba una Layer mientras estaba activado Bloq. Mayús, quedaba el rgb_mode como el de la capa LOWER o RAISE.
-Ajuste en mapeo:
Cambié las mouse keys y las de teclas de brillo.
* Update readme.md
* Se borra carpeta /rev2_latam, para dejar todo enlatado y andando desde /rev2.
Esto para que el PR solo sea agregar el keymap "fraanrosi".
* Quito cambio de helix.h
Quito lo que ya no es necesario, para hacer el pull request limpio.
* Update Readme.mp
* Revert "Update Readme.mp"
This reverts commit eb9a2712b0.
* Update readme.md
* Clean up, organization, indent fixes
* Update readme.md
* Latam version of Helix/rev2/back
. Latam adaptation of keymap(whit "ñ")
. 3 layers (Qwerty, Lower, Raise)
. Underglow light changes while pressing Lower(BLUE) and Raise(RED), then it returns to prior mode.
(cherry picked from commit 974be350115b2d33b55edbc02e3b5281e1f856d7)
* Se añade Keymap.
* Agrego un pdf preliminar del mapeo y reubico el keymap a carpeta correspondiente.
* Ajustes en mapeo para simplificar.
Agrego Mark Down con mapeo.
Creo carpeta "layers mapping" para guardar lo correspondiente a mapeo.
* Update keymap.md
* Rename keymap.md to readme.md
* Organización en general y cambio de configuración de "back" a "under"(que era la que correspondía).
.Ahora los leds underglow responden mejor.
* -Se agrega indicador rgb para el bloq mayús.
-Se agrega manejo del rgb_tog.
-Se agrega botón para reset(del teclado).
-Ajustes de keymap varios.
-Limpieza de código.
* Update readme.md
* Update readme.md
* Update readme.md
* adding helix-keyboard.png
* Update readme.md
* -Se agregan Mouse Keys (para manejo del mouse con el teclado).
-Se hace fix en el modo "Bloq. Mayús" (Se persiste el cambio de RGB mode mientras el Bloq. Mayús está activado).
* Cambios en el Keymap para mayor comodidad del uso del mouse.
* Update readme.md
* Update readme.md
* -Fixeo de comportamiento del "Bloq. Mayús":
Cuando se presionaba una Layer mientras estaba activado Bloq. Mayús, quedaba el rgb_mode como el de la capa LOWER o RAISE.
-Ajuste en mapeo:
Cambié las mouse keys y las de teclas de brillo.
* Update readme.md
* Se borra carpeta /rev2_latam, para dejar todo enlatado y andando desde /rev2.
Esto para que el PR solo sea agregar el keymap "fraanrosi".
* Quito cambio de helix.h
Quito lo que ya no es necesario, para hacer el pull request limpio.
* Update Readme.mp
* Revert "Update Readme.mp"
This reverts commit eb9a2712b0.
* Update readme.md
* Update readme.md
* Clean up, organization, indent fixes
* Update readme.md
Latam version of Helix/rev2/back
. Latam adaptation of keymap(whit "ñ")
. 3 layers (Qwerty, Lower, Raise)
. Underglow light changes while pressing Lower(BLUE) and Raise(RED), then it returns to prior mode.
(cherry picked from commit 974be350115b2d33b55edbc02e3b5281e1f856d7)
Se añade Keymap.
Agrego un pdf preliminar del mapeo y reubico el keymap a carpeta correspondiente.
Ajustes en mapeo para simplificar.
Agrego Mark Down con mapeo.
Creo carpeta "layers mapping" para guardar lo correspondiente a mapeo.
Update keymap.md
Rename keymap.md to readme.md
Organización en general y cambio de configuración de "back" a "under"(que era la que correspondía).
.Ahora los leds underglow responden mejor.
-Se agrega indicador rgb para el bloq mayús.
-Se agrega manejo del rgb_tog.
-Se agrega botón para reset(del teclado).
-Ajustes de keymap varios.
-Limpieza de código.
Update readme.md
Update readme.md
Update readme.md
adding helix-keyboard.png
Update readme.md
-Se agregan Mouse Keys (para manejo del mouse con el teclado).
-Se hace fix en el modo "Bloq. Mayús" (Se persiste el cambio de RGB mode mientras el Bloq. Mayús está activado).
Cambios en el Keymap para mayor comodidad del uso del mouse.
Update readme.md
Update readme.md
-Fixeo de comportamiento del "Bloq. Mayús":
Cuando se presionaba una Layer mientras estaba activado Bloq. Mayús, quedaba el rgb_mode como el de la capa LOWER o RAISE.
-Ajuste en mapeo:
Cambié las mouse keys y las de teclas de brillo.
Update readme.md
Se borra carpeta /rev2_latam, para dejar todo enlatado y andando desde /rev2.
Esto para que el PR solo sea agregar el keymap "fraanrosi".
Quito cambio de helix.h
Quito lo que ya no es necesario, para hacer el pull request limpio.
Update Readme.mp
Revert "Update Readme.mp"
This reverts commit eb9a2712b0.
Update readme.md
Clean up, organization, indent fixes
Update readme.md
* Changes and corrections were made to Pull Request.
* Since the last change, readme.md and comment in keymap.c were to be updated.
The initialization of the submodules would succeed, but the result of the subsequent
check_submodules() run wasn't checked correctly.
Co-authored-by: Stefan Schulze <stefan.andre.schulze@posteo.de>
Current wording of IGNORE_MOD_TAP_INTERRUPT is incorrect, and very confusing when attempting to correct a somewhat common issue for quick typists that have Mod-Tap on a commonly used key. Research indicates this wording has been incorrect for some time, and has tripped up others attempting to solve the issue of Mod + Key being sent, when Tap + Key is expected after quickly pressing keys.
* Redo Arm DAC implementation for additive, wavetable synthesis, sample playback
changes by Jack Humbert on an implementation for DAC audio on arm/chibios platforms
this commits bundles the changes from the arm-dac-work branch focused on audio/audio_arm.* into one commit (leaving out the test-keyboard)
f52faeb5d (origin/arm-dac-work) add sample and wavetable examples, parsers for both
-> only the changes on audio_arm_.*, the keyboard related parts are split off to a separate commit
bfe468ef1 start morphing wavetable
474d100b5 refined a bit
208bee10f play_notes working
3e6478b0b start in-place documentation of dac settings
3e1826a33 fixed blip (rounding error), other waves, added key selection (left/right)
73853d651 5 voices at 44.1khz
dfb401b95 limit voices to working number
9632b3379 configuration for the ez
6241f3f3b notes working in a new way
* Redo Arm DAC implementation for additive, wavetable synthesis, sample playback
changes by Jack Humbert on an implementation for DAC audio on arm/chibios platforms
this commit splits off the plank example keymap from commit
f52faeb5d (origin/arm-dac-work) add sample and wavetable examples, parsers for both
* refactoring: rename audio_ to reflect their supported hardware-platform and audio-generation method: avr vs arm, and pwm vs dac
* refactoring: deducplicate ISR code to update the pwm duty-cycle and period in the avr-pwm-implementation
pulls three copies of the same code into one function
which should improve readability and maintainability :-)
* refactoring: move common code of arm and avr implementation into a separate/new file
* refactoring: audio_avr_pwm, renaming defines to decouple them from actually used timers, registers and ISRs
* refactoring: audio_avr_pwm - replacing function defines with plain register defines
aligns better with other existing qmk code (and the new audio_arm_pwm) doing similar pwm thing
* add audio-arm-pwm
since not all STM32 have a DAC onboard (STM32F2xx and STM32F3xx), pwm-audio is an alternative (STM32F1xx)
this code works on a "BluePill" clone, with an STM32F103C8B
* clang-format changes on quantum/audio/* only
* audio_arm_dac: stopping the notes caused screeching when using the DAC audio paths
* audio_arm_pwm: use pushpull on the pin; so that a piezzo can be hooked up direclty without additional components (opendrain would require an external pullup)
* refactoring: remove unused file from/for atmel-avr chips
* refactoring: remove unused (avr) wavetable file
* audio_arm_dac: adapt dac_end callback to changed chibios DAC api
the previous chibios (17.6.0) passed along a pointer into the buffer plus a sample_count (which are/already where included in the DACDrivre object) - the current chibios (19.1.0) only passes the driver object.
this patch ports more or less exactly what the previous chibios ISR code did: either have the user-callback work the first or second half of the buffer (dacsample_t pointer, with half the DAC_BUFFER_SIZE samples) by adjusting the pointer and sample count
* audio-arm-dac: show a compile-warning on undefined audio-pins
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* audio_arm_dac: switch from exemplary wavetable generation to sine only
sine+triangle+squrare is exemplary, and not realy fit for "production" use
'stairs' are usefull for debugging (hardware, with an oscilloscope)
* audio_arm_dac: enable output buffers in the STM32
to drive external loads without any additional ciruitry - external opamps and such
* audio: prevent out-of-bounds array access
* audio_arm_dac: add output-frequency correcting factor
* audio_arm_pwm: get both the alternate-function and pm-callback variants back into working condition
and do some code-cleanup, refine documentation, ...
* audio_arm_pwm: increase pwm frequency for "higher fidelity"
on the previous .frequency=100000 higher frequency musical notes came out wrong
(frequency measured on a Tektronix TDS2014B)
note | freq | arm-pwm
C2 | 65.4 | 65.491
C5 | 523.25 | 523.93
C6 | 1046.5 | 1053.38
C7 | 2093 | 2129
C8 | 4186 | 4350.91
with .frequency = 500000
C8 | 4186 | 4204.6
* audio refactoring: remove unused variables
* audio_arm_dac: calibrate note tempo: with a tempo of 60beats-per-second a whole-note should last for exactly one second
* audio: allow feature selection in rules.mk
so the user can switch the audio driver between DAC and PWM on STM32 boards which support both (STM32F2 and up)
or select the "pin alternate" pwm mode, for example on STM32F103
* audio-refactoring: move codeblocks in audio.[ch] into more coherent groups
and add some inline documentation
* audio-refactoring: cleanup and streamline common code between audio_arm_[dac|pwm]
untangeling the relation between audio.c and the two drivers
and adding more documenting comments :-)
* audio_avr_pwm: getting it back into working condition, and cleanup+refactor
* audio-refactoring: documentation and typo fixes
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* audio-refactoring: cleanup defines, inludes and remove debug-prints
* audio_chibios_dac: define&use a minimal sampling rate, based on the available tone-range
to ease up on the cpu-load, while still rendering the higher notes/tones sufficiently
also reenable the lower tones, since with the new implementation there is no evidence of them still beeing 'bugged'
* audio-refactoring: one common AUDIO_MAX_VOICES define for all audio-drivers
* audio-chibios-pwm: pwm-pin-allternate: make the the timer, timer-channel and alternate function user-#definable
* audio_chibios_dac: math.h has fmod for this
* Redo Arm DAC implementation for additive, wavetable synthesis, sample playback
update Jack Humberts dac-example keymaps for the slight changes in the audio-dac interface
* audio-refactoring: use a common AUDIO_PIN configuration switch instead of defines
have the user select a pin by configuration in rules.mk instead of a define in config.h
has the advantage of beeing in a common form/pattern across all audio-driver implementations
* audio-refactoring: switch backlight_avr.c to the new AUDIO_PIN defines
* audio-common: have advance_note return a boolean if the note changed, to the next one in the melody beeing played
* audio-chibios-pwm: fix issue with ~130ms silence between note/frequency changes while playing a SONG
through trial,error and a scope/logic analyzer figured out Chibios-PWMDriver (at least in the current version) misbehaves if the initial period is set to zero (or one; two seems to work); when thats the case subsequent calls to 'pwmChhangePeriod' + pwmEnableChannel took ~135ms of silence, before the PWM continued with the new frequency...
* audio-refactoring: get 'play_note' working again
with a limited number of available voices (say AUDIO_VOICES_MAX=1) allow new frequencies to be played, by discarding the oldest one in the 'frequencies' queue
* audio: set the fallback driver to DAC for chibios and PWM for all others (==avr at the moment)
* audio-refactoring: moore documentation
and some cleanup
* audio-avr-pwm: no fallback on unset AUDIO_PIN
this seems to be the expected behaviour by some keyboards (looking at ckeys/handwire_101:default) which otherwise fail to build because the firmware-image ends up beeing too large for the atmega... so we fail silently instead to keep travis happy
* audio-refactoring: untangling terminology: voice->tone
the code actually was working on tones (combination of pitch/frequency, duration, timbre, intensity/volume) and not voices (characteristic sound of an instrument; think piano vs guitar, which can be played together, each having its own "track" = voice on a music sheet)
* audio-pwm: allow freq=0 aka a pause/rest in a SONG
continue processing, but do not enable pwm units, since freq=0 wouldn't produce any sound anyway (and lead to division by zero on that occasion)
* audio-refactoring: audio_advance_note -> audio_advance_state
since it does not only affect 'one note', but the internally kept state as a whole
* audio-refactoring: untangling terminology: polyphony
the feature om the "inherited" avr code has little to do with polyphony (see wikipedia), but is more a time-multiplexing feature, to work around hardware limitations - like only having one pwm channel, that could on its own only reproduce one voice/instrument at a time
* audio-chibios-dac: add zero-crossing feature
have tones only change/stop when the waveform approaches zero - to avoid audible clicks
note that this also requires the samples to start at zero, since the internally kept index into the samples is reset to zero too
* audio-refactoring: feature: time-multiplexing of tones on a single output channel
this feature was in the original avr-pwm implementation misnomed as "polyphony"
with polyphony_rate and so on; did the same thing though: time-multiplexing multiple active notes so that a single output channel could reproduce more than one note at a time (which is not the same as a polyphony - see wikipedia :-) )
* audio-avr-pwm: get music-mode working (again) on AVRs
with both pwm channels, or either one of the two :-)
play_notes worked already - but music_mode uses play_note
* audio-refactoring: split define MAX_SIMULTANEOUS_TONES -> TONE_STACKSIZE
since the two cases are independant from one another, the hardware might impose limitations on the number of simultaneously reproducable tones, but the audio state should be able to track an unrelated number of notes recently started by play_note
* audio-arm-dac: per define selectable sample-luts
plus generation script in ./util
* audio-refactoring: heh, avr has a MIN...
* audio-refactoring: add basic dac audio-driver based on the current/master implementation
whereas current=d96380e65496912e0f68e6531565f4b45efd1623
which is the state of things before this whole audio-refactoring branch
boiled down to interface with the refactored audio system = removing all
redundant state-managing and frequency calculation
* audio-refactoring: rename audio-drivers to driver_$PLATFORM_$DRIVER
* audio-arm-pwm: split the software/hardware implementations into separate files
which saves us partially from a 'define hell', with the tradeoff that now two somewhat similar chibios_pwm implementations have to be maintained
* audio-refactoring: update documentation
* audio-arm-dac: apply AUDIO_PIN defines to driver_chibios_dac_basic
* audio-arm-dac: dac_additive: stop the hardware when the last sample completed
the audio system calls for a driver_stop, which is delayed until the current sample conversion finishes
* audio-refactoring: make function-namespace consistent
- all (public) audio functions start with audio_
- also refactoring play*_notes/tones to play*_melody, to visually distance it a bit from play*_tone/_note
* audio-refactoring: consistent define namespace: DAC_ -> AUDIO_DAC_
* audio-arm-dac: update (inline) documentation regarding MAX for sample values
* audio-chibios-dac: remove zero-crossing feature
didn't quite work as intended anyway, and stopping the hardware on close-to-zero seems to be enought anyway
* audio-arm-dac: dac_basic: respect the configured sample-rate
* audio-arm-pwm: have 'note_timbre' influence the pwm-duty cycle
like it already does in the avr implementation
* audio-refactoring: get VIBRATO working (again)
with all drivers (verified with chibios_[dac|pwm])
* audio-arm-dac: zero-crossing feature (Mk II)
wait for the generated waveform to approach 'zero' before either turning off the output+timer or switching to the current set of active_tones
* audio-refactoring: re-add note-resting -> introduce short_rest inbetween
- introduce a short pause/rest between two notes of the same frequency, to separate them audibly
- also updating the refactoring comments
* audio-refactoring: cleanup refactoring remnants
remove the former avr-isr code block - since all its features are now refactored into the different parts of the current system
also updates the TODOS
* audio-refactoring: reserve negative numbers as unitialized frequencies
to allow the valid tone/frequency f=0Hz == rest/pause
* audio-refactoring: FIX: first note of melody was missing
the first note was missing because 'goto_next_note'=false overrode a state_change=true of the initial play_tone
and some code-indentations/cleanup of related parts
* audio-arm-dac: fix hardware init-click
due to wron .init= value
* audio-refactoring: new conveniance function: audio_play_click
which can be used to further refactor/remove fauxclicky (avr only) and/or the 'clicky' features
* audio-refactoring: clang-format on quantum/audio/*
* audio-avr-pwm: consecutive notes of the same frequency get a pause inserted inbetween by audio.c
* audio-refactoring: use milliseconds instead of seconds for 'click' parameters
clicks are supposed to be short, seconds make little sense
* audio-refactoring: use timer ticks instead of counters
local counters were used in the original (avr)ISR to advance an index into the lookup tables (for vibrato), and something similar was used for the tone-multiplexing feature
decoupling these from the (possibly irregular) calls to advance_state made sesne, since those counters/lookups need to be in relation to a wall-time anyway
* audio-refactoring: voices.c: drop 'envelope_index' counter in favour of timer ticks
* audio-refactoring: move vibrato and timbre related parts from audio.c to voices.c
also drops the now (globally) unused AUDIO_VIBRATO/AUDIO_ENABLE_VIBRATO defines
* audio.c: use system-ticks instead of counters the drivers have to take care of for the internal state posision
since there already is a system-tick with ms resolution, keeping count separatly with each driver implementation makes little sense; especially since they had to take special care to call audio_advance_state with the correct step/end parameters for the audio state to advance regularly and with the correct pace
* audio.c: stop notes after new ones have been started
avoids brief states of with no notes playing that would otherwise stop the hardware and might lead to clicks
* audio.c: bugfix: actually play a pause
instead of just idling/stopping which lead the pwm drivers to stop entirely...
* audio-arm-pwm: pwm-software: add inverted output
new define AUDIO_PIN_ALT_AS_NEGATIVE will generate an inverted signal on the alternate pin, which boosts the volume if a piezo is connected to both AUDIO_PIN and AUDIO_PIN_ALT
* audio-arm-dac: basic: handle piezo configured&wired to both audio pins
* audio-refactoring: docs: update for AUDIO_PIN_ALT_AS_NEGATIVE and piezo wiring
* audio.c: bugfix: use timer_elapsed32 instad of keeping timestamps
avoids running into issues when the uint32 of the timer overflows
* audio-refactoring: add 'pragma once' and remove deprecated NOTE_REST
* audio_arm_dac: basic: add missing bracket
* audio.c: fix delta calculation
was in the wrong place, needs to use the 'last_timestamp' before it was reset
* audio-refactoring: buildfix: wrong legacy macro for set_timbre
* audio.c: 16bit timerstamps suffice
* audio-refactoring: separate includes for AVR and chibios
* audio-refactoring: timbre: use uint8 instead of float
* audio-refactoring: duration: use uint16 for internal per-tone/note state
* audio-refactoring: tonemultiplexing: use uint16 instead of float
* audio-arm-dac: additive: set second pin output-low
used when a piezo is connected to AUDIO_PIN and AUDIO_PIN_ALT, with PIN_ALT_AS_NEGATIVE
* audio-refactoring: move AUDIO_PIN selection from rules.mk to config.h
to be consistent with how other features are handled in QMK
* audio-refactoring: buildfix: wrong legacy macro for set_tempo
* audio-arm-dac: additive: set second pin output-low -- FIXUP
* audio.c: do duration<>ms conversion in uint instead of float
on AVR, to save a couple of bytes in the firmware size
* audio-refactoring: cleanup eeprom defines/usage
for ARM, avr is handled automagically through the avr libc and common_features.mk
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* audio.h: throw an error if OFF is larger than MAX
* audio-arm-dac: basic: actually stop the dac-conversion on a audio_driver_stop
to put the output pin in a known state == AUDIO_DAC_OFF_VALUE, instead of just leaving them where the last conversion was... with AUDIO_PIN_ALT_AS_NEGATIVE this meant one output was left HIGH while the other was left LOW
one CAVEAT: due to this change the opposing squarewave when using both A4 and A5 with AUDIO_PIN_ALT_AS_NEGATIVE
show extra pulses at the beginning/end on one of the outputs, the two waveforms are in sync otherwise.
the extra pusles probably matter little, since this is no high-fidelity sound generation :P
* audio-arm-dac: additive: move zero-crossing code out of dac_value_generate
which is/should be user-overridable == simple, and doing one thing: providing sample values
state-transitions necessary for the zero crossing are better handled in the surrounding loop in the dac_end callback
* audio-arm-dac: dac-additive: zero-crossing: ramping up or down
after a start trigger ramp up: generate values until zero=OFF_VALUE is reached, then continue normally
same in reverse for strop trigger: output values until zero is reached/crossed, then keep OFF_VALUE on the output
* audio-arm-dac: dac-additive: BUGFIX: return OFF_VALUE when a pause is playing
fixes a bug during SONG playback, which suddenly stopped when it encoutnered a pause
* audio-arm-dac: set a sensible default for AUDIO_DAC_VALUE_OFF
1/2 MAX was probably exemplary, can't think of a setup where that would make sense :-P
* audio-arm-dac: update synth_sample/_wavetable for new pin-defines
* audio-arm-dac: default for AUDIO_DAC_VALUE_OFF
turned out that zero or max are bad default choices:
when multiple tones are played (>>5) and released at the same time (!), due to the complex waveform never reaching 'zero' the output can take quite a while to reach zero, and hence the zero-crossing code only "releases" the output waaay to late
* audio-arm-dac: additive: use DAC for negative pin
instead of PAL, which only allows the pin to be configured as output; LOW or HIGH
* audio-arm-dac: more compile-time configuration checks
* audio-refactoring: typo fixed
* audio-refactoring: clang-format on quantum/audio/*
* audio-avr-pwm: add defines for B-pin as primary/only speaker
also updates documentation.
* audio-refactoring: update documentation with proton-c config.h example
* audio-refactoring: move glissando (TODO) to voices.c
refactored/saved from the original glissando implementation in then upstream-master:audio_avr.c
still needs some work though, as it is now the calculation *should* work, but the start-frequency needs to be tracked somewhere/somehow; not only during a SONG playback but also with user input?
* audio-refactoring: cleanup: one round of aspell -c
* audio-avr-pwm: back to AUDIO_PIN
since config_common.h expands them to plain integers, the AUDIO_PIN define can directly be compared to e.g. B5
so there is no need to deal with separate defines like AUDIO_PIN_B5
* audio-refactoring: add technical documentation audio_driver.md
which moves some in-code documentation there
* audio-arm-dac: move AUDIO_PIN checks into c-code
instead of doing everything with the preprocessor, since A4/A5 do not expand to simple integers, preprocessor int-comparison is not possible. but necessary to get a consistent configuration scheme going throughout the audio-code... solution: let c-code handle the different AUDIO_PIN configurations instead (and leave code/size optimizations to the compiler)
* audio-arm-dac: compile-fix: set AUDIO_PIN if unset
workaround to get the build going again, and be backwarts compatible to arm-keyboards which not yet set the AUDIO_PIN define. until the define is enforced through an '#error"
* audio-refactoring: document tone-multiplexing feature
* audio-refactoring: Apply suggestions from documentation review
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* audio-refactoring: Update docs/audio_driver.md
* audio-refactoring: docs: fix markdown newlines
Terminating a line in Markdown with <space>-<space>-<linebreak> creates an HTML single-line break (<br>).
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* audio-arm-dac: additive: fix AUDIO_PIN_ALT handling
* audio-arm-pwm: align define naming with other drivers
Co-authored-by: Joel Challis <git@zvecr.com>
* audio-refactoring: set detault tempo to 120
and add documentation for the override
* audio-refactoring: update backlight define checks to new AUDIO_PIN names
* audio-refactoring: reworking PWM related defines
to be more consistent with other QMK code
Co-authored-by: Joel Challis <git@zvecr.com>
* audio-arm: have the state-update-timer user configurable
defaulting to GPTD6 or GPTD8 for stm32f2+ (=proton-c)
stm32f1 might need to set this to GPTD4, since 6 and 8 are not available
* audio-refactoring: PLAY_NOTE_ARRAY was already removed in master
* Add prototype for startup
* Update chibiOS dac basic to disable pins on stop
* Add defaults for Proton C
* avoid hanging audio if note is completely missed
* Don't redefine pins if they're already defined
* Define A4 and A5 for CTPC support
* Add license headers to keymap files
* Remove figlet? comments
* Add DAC config to audio driver docs
* Apply suggestions from code review
Co-authored-by: Jack Humbert <jack.humb@gmail.com>
* Add license header to py files
* correct license header
* Add JohSchneider's name to modified files
AKA credit where credit's due
* Set executable permission and change interpeter
* Add 'wave' to pip requirements
* Improve documentation
* Add some settings I missed
* Strip AUDIO_DRIVER to parse the name correctly
* fix depreciated
* Update util/audio_generate_dac_lut.py
Co-authored-by: Jack Humbert <jack.humb@gmail.com>
* Fix type in clueboard config
* Apply suggestions from tzarc
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Johannes <you@example.com>
Co-authored-by: JohSchneider <JohSchneider@googlemail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joshua Diamond <josh@windowoffire.com>
Co-authored-by: Jack Humbert <jack.humb@gmail.com>
* Fixed some comments in the defines file.
* Replaced the Git command layer with a Windows Terminal shortcut layer.
* Added numbered tab switching to the Windows Terminal layer.
* Added 'new tab' and 'command pane' commands to the Windows Terminal layer.
* Shortened the USB polling interval for the Iris to 1 millisecond.
* Disabled old style macros and functions for the Iris.
* add feature_unicode.md translation
* consolidate sentence end
* update based on comment
* update based on comment
* update based on comment
* update based on comment
* [Keyboard] YMDK YMD40 v2
* fork default keymap into default and factory
- factory keymap is as assigned by the extracted JSON provided by the vendor
- default keymap is based on the Planck
* add AUDIO_SUPPORTED rule per drashna
* modify factory keymap's readme
Recommend users copy the default keymap instead.
* Remove GCC check from debug
* Remove platform logic from common.mk
* Refactor platform logic within print.h
* restore debug.c format
* headers
* Rename function pointer type
* review comments
* Update tmk_core/common/printf.c
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Format
Co-authored-by: Nick Brassel <nick@tzarc.org>
* LED Matrix: add led_matrix_types.h and implement g_led_config
* Set correct flags for non-"modifier" LEDs
* Clean up docs a little
* Add license headers for [led,rgb]_matrix_types.h
* Add default ISO Windows layout for Durgod/K320
* Duplicate default_iso to default_iso_mac
Swap the L{GUI,ALT} keys to match the mac layout, and remove the
windows key lock functionality.
* Remove windows-key lock in default_iso
* Fixup wonky macro layout inherited from ansi keymap
* Add Z70Ultra which is a Hotsawp RGB 65% keyboard
* Update keyboards/melgeek/z70ultra/z70ultra.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/rev1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update readme.md
* Update info.json
update the name of layout to consistent the keyboard.
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/info.json
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add Z70Ultra
* Support Z70Ultra
[Modified] info.json to support two different layouts
[Add] rules.mk to support default folder
* Update keyboards/melgeek/z70ultra/rev1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/z70ultra/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* remove excessive arguments from LAYOUT_split_space
* Update keyboards/melgeek/z70ultra/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/z70ultra.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/z70ultra.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/rev1/rules.mk
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/melgeek/z70ultra/keymaps/via/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Use macro replace with the literal for CS & SW
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* [Keyboard] Support MJ61 which is a 60% ANSI STD Hotswap RGB keyboard
* Update keyboards/melgeek/mj61/mj61.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/melgeek/mj61/mj61.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* [Keyboard] MJ61 Add license header for files and the link for readme
* Update keyboards/melgeek/mj61/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/mj61/rev1/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/mj61/rev1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/mj61/mj61.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/melgeek/mj61/mj61.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add GPL for files
* Update keymaps/default/keymap.c
* Update keymaps/via/keymap.c
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/melgeek/z70ultra/z70ultra.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* [Keyboard] Update MOJO75 to support multi version and Update the LED's
ID of RGB Matrix
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* added default as a starting point
* added readme per guidelines
* made necessary changed to keymap to follow guidelines
* changed debounce mode for more smooth usage at the cost of mem
* increased polling interval
* Revert "made necessary changed to keymap to follow guidelines"
yikes! I modified the WRONG directory. reverted.
This reverts commit 8ba3d97af5.
* reverted commit that modified file in incorrect directory. modified intended file.
* added license tp config.h
* enable LTO for smaller firmware size
* delete since this was added to userspace rules.mk
* readme updates and new images
* Add -j to compile and flash commands in userpsace
* Enable NKRO
* Enable NKRO, VIA, LTO by default
* Stanrc85-ansi readme update
* Stanrc85-alice readme
* quick RGB layer indicator fix in keymap
* Simplify encoder code and clean up keymaps.
-Removed overly complex VIA encoder code. It wasn't adding any value and was confusing users who were trying to customize encoder functionality on VIA keymaps.
-Replaced KC_TILDE with KC_HOME in all keymaps, as KC_TILDE sends a left shift, which was confusing some folks as they tested their build.
-Move layer names to enum
* Change encoder_update_kb to encoder_update_user per PR feedback
* ws2812: Fix number of nops for AVR at 8 MHz
When trying to calculate the number of nops for AVR running at 8 MHz,
the value of `w3` is expected to be negative; however, because `F_CPU`
is defined in tmk_core/avr.mk with the `UL` suffix, the preprocessor
performs its calculations using `unsigned long`, getting a very large
positive number instead of the expected negative number; this then
results in generating code with a huge number of nops. Fix the broken
calculations by performing a comparison before subtraction, so that the
unsigned number wraparound does not occur.
The keyboard which triggers the problem is `handwired/promethium`; the
buggy code silently compiles, but the resulting timings would be
completely wrong.
* ws2812: Clean up the code after the 8 MHz fix
Remove old code which was unsuccessfully trying to clamp negative w1, w2
and w3 values to 0, and set w1_nops, w2_nops and w3_nops directly.
* Don't block keys during startup animation
* More refinements related to startup and debug state
* restore key logging
* some cleanup on scan rate reporting
* trim some fat
* better lighting to indicate jumped to bootloader
* use eeprom for state restoration
* a little reorganization
* report version immediately when turn on debug
* hold-to-adjust for hue, sat, val
* cformat
* reorg rules.mk settings, fix compile with CONSOLE_ENABLE=no
* simplify spidey3 userspace
* NULL in layer list caused buggy behavior
* more bugfix
* update numpad layout to match matt30 MT3 /dev/tty keycaps
* swap emdash and endash
* map shift+backspace to delete
* removing NO_ACTION_ONSHOT makes the firmware SMALLER ?!
* cformat
* improve spi_glow
* disable shift-backspace = delete by default
* resolve race condition between suspend and wake in LUFA
* avoid multiple calls to suspend_power_down() / suspend_wakeup_init()
* Remove duplicate suspend_power_down_kb() call
* pause on wakeup to wait for USB state to settle
* need the repeated suspend_power_down() (that's where the sleep is)
* more efficient implementation
* fine tune the pause after sending wakeup
* speculative chibios version of pause-after-wake
* make wakeup delay configurable, and adjust value
* better location for wakeup delay
* generate rules.mk from a json mapping
* generate rules.mk from a json mapping
* support for config.h from json maps
* improve the mapping system
* document the mapping system
* move data/maps to data/mappings
* fix flake8 errors
* fixup LED_MATRIX_DRIVER
* remove product and description from the vision_division keymap level
* reduce the complexity of generate-rules-mk
* add tests for the generate commands
* fix qmk doctor when submodules are not clean
* at90usb162 support
* fix missing bracket
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add support for 8 buttons to mouse report
This includes support for 8 buttons in mousekeys. However, this does move the keys around due to the fact that the last mousekey keycode is already 0xFF, so any past that would not work with register_code and the like, breaking them for tap hold keys, encoders, and other features.
* Update mouse key docs
* Add changes based on feedback
* Fix VUSB report size comment
Because drashna red gud
* Fix typo in action.c
* Fix IS_MOUSE_BUTTON check
* Change start range for mousekeys so that the end is 0xFF properly
* condense mousekeys check
* fix matrix_io_delay() timing in quantum/matrix.c
* Updated comments explaining the need for matrix_io_delay() in quantum/matrix.c
* fix matrix_io_delay() timing in quantum/split_common/matrix.c
* Update quantum/matrix.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update quantum/split_common/matrix.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update quantum/matrix.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update quantum/split_common/matrix.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* add waitOutputPinValid() and wait_cpuclock() into quantum/quantum.h and tmk_core/common/wait.h
* add matrix_output_select_delay() and matrix_output_unselect_delay()
* fix quantum/matrix_common.c, tmk_core/common/matrix.h
* fix tmk_core/common/wait.h
* fix quantum/quantum.h, tmk_core/common/wait.h
* waitOutputPinValid() rename to waitInputPinDelay() in quantum/quantum.h.
* waitOutputPinValid() rename to waitInputPinDelay() in quantum/matrix_common.c
* update tmk_core/common/wait.h
* update comment in quantum/matrix.c, quantum/split_common/matrix.c
* update quantum/quantum.h: Make more margin in the GPIO_INPUT_PIN_DELAY default value.
Co-authored-by: Ryan <fauxpark@gmail.com>
* Allow recording of the last matrix activity time, to simplify implementation of display timeouts and the like.
* Add requested changes from code review.
* Simplify split matrix last changed.
* add support for specifying BOARD in info.json
* move BOARD from rules.mk to info.json for clueboard
* fix keyboards that do not require board
* remove out of compliance values
* use the schema to eliminate custom code
* Update docs/reference_info_json.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* make flake8 happy
* bugfix
* do not overwrite make vars from json
Co-authored-by: Ryan <fauxpark@gmail.com>
* Make parameters from info.json available to the build system
* move all clueboard settings to info.json
* code formatting
* make flake8 happy
* make flake8 happy
* make qmk lint happy
* Add support for specifying led indicators in json
* move led indicators to the clueboard info.json
* Apply suggestions from code review
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* add missing docstring
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* Update ADB impelmentation in tmk_core to recent version.
Pcked from tmk_keyboard repository revision: 48d696443857512d45f9a7329e0dd0a76345860f
* Restore convenient ADB functions used in QMK port.
* Do cformat.
* Rewrite APA102 support
The APA102 source was broken by commit 16a15c1cfc as it did not include the
quantum header. This commit addresses that, as well as other issues with
transferring bytes over the SPI interface, i.e. it was not setting the
clock pin back to low after sending a bit.
The deviation when sending the end frame is kept, but updated to the
latest from the referenced project.
Finally, these changes expose the global LED brightness parameter
of the APA102. Brightness values are configurable through
`APA102_DEFAULT_BRIGHTNESS` and `APA102_MAX_BRIGHTNESS`.
* Fix typo in led brightness extern
* Move driver out of AVR directory and add delay for ARM
* Experimental APA102 support on AVR and ARM
Co-authored-by: Alde Rojas <hello@alde.io>
* Refactor apa102_send_byte() calls to a loop
* Implement io_wait function for ARM
* Move APA102 drivers to own directory, fix copyright notice
* Add APA102 keymap to handwired/onekey
* Simplify RGBLIGHT_ENABLE/DRIVER option handling
Co-authored-by: Mikkel Jeppesen <2756925+Duckle29@users.noreply.github.com>
* Add modifier state to the split transport
This adds modifier state to the i2c and serial transport for split
keyboards. The purpose of this is to allow e.g. displaying modifier
state on the slave side of a split keyboard on an oled. This adds one
byte to the data transferred between halves.
This also fixes a missing ifdef guard for BLACKLIGHT_ENABLE.
Break modifiers into real/weak/oneshot
Fix incorrect slave serial mod setting
Fix typo in serial weal mod setter
Fix build errors for the I2C code that I introduced
Code cleanup and formatting per project preferences
Correctly get oneshot mods
Fix missing braces
Remove unneeded ifdef guard
Make the added state transport optional
Add documentation for the new define to enable this feature
Fix stray grave mark
* Fix error introduced in conflict resolution
* Split dmac_desc declaration and definition
According to the official documentation[1] gcc 10 is more strict about
correct extern usage.
I've had to move the definition of dmac_desc and dmac_desc_wb from
i2c_master.h to the corresponding .c file. This could be an issue if
anyone includes the i2c_master.h file without liking with the object
file.
[1]: https://gcc.gnu.org/gcc-10/porting_to.html
* Remove the keymap_config definition from keymaps
The keymap_config def was conflicting with the one found in
tmk_core/common/magic.c. Declaring it extern in magic.c breaks a bunch
of keyboard that rely on that declaration (like the ergodox). Instead
I've removed the one found in the keymap.c of the massdrop alt.
The same change will have to be made to other keyboards.
* Disable almost all ChibiOS subsystems.
* Modify ChibiOS config updater script to fixup mcuconf include, use develop as base instead of master.
* Add default early-init bootloader to F042/F072.
* Back to 100k freq.
- Set all other ChibiOS defaults to 'off', when not targeting Proton-C
- Modified all existing F303 boards to point at the QMK_PROTON_C to ensure repeatable binary output
- Modified version.h generation so that SKIP_VERSION=yes generates the same output
# QMK Breaking Changes - 2021 February 27 Changelog
## Changes Requiring User Action
The following keyboards have had their source moved within QMK:
Old Keyboard Name | New Keyboard Name
:---------------- | :----------------
bear_65 | jacky_studio/bear_65
s7_elephant/rev1 | jacky_studio/s7_elephant/rev1
s7_elephant/rev2 | jacky_studio/s7_elephant/rev2
aplx6 | aplyard/aplx6/rev1
southpaw75 | fr4/southpaw75
The [Aplyard Aplx6 rev2](https://github.com/qmk/qmk_firmware/tree/0.12.0/keyboards/aplyard/aplx6/rev1) and the [FR4Boards Unix60](https://github.com/qmk/qmk_firmware/tree/0.12.0/keyboards/fr4/unix60) have also been added as part of these changes.
Additionally, the `handwired/bluepill/bluepill70` keyboard has been removed.
## Core Changes
### ChibiOS Update and Config Migration
QMK's ChibiOS and ChibiOS-Contrib submodules have been updated to version 20.3.2.
Along with this, QMK now provides default configuration files for all commonly-supported ARM microcontrollers running on ChibiOS. As such, keyboards are now only required to define settings which differ from the defaults, thereby reducing the size of pull requests for keyboards running atop ChibiOS.
### QMK Infrastructure and Internals
Python is now required to build QMK. The minimum Python version has been increased to 3.7.
The power of `info.json` has been massively expanded. Most keyboard parameters can now be expressed in `info.json` instead of `config.h`/`rules.mk`. This should make maintaining keyboards easier, and will enable tooling that can allow non-technical users to add and maintain QMK keyboards without writing any code.
To ease migration a new command has been provided, `qmk generate-info-json -kb <keyboard>`. You can use this command to generate a complete `info.json` file for a keyboard and then remove the duplicate information from `config.h` and `rules.mk`.
Detailed example showing how to generate a new info.json and identify duplicate keys:
* Fixed up build dependencies so that generated files are made available before compiling any object files ([#11435](https://github.com/qmk/qmk_firmware/pull/11435))
* Include `stdbool.h` in `uart.h` to fix compiler errors ([#11728](https://github.com/qmk/qmk_firmware/pull/11728))
* Decouple USB events from the USB interrupt handler in ChibiOS ([#10437](https://github.com/qmk/qmk_firmware/pull/10437))
* Fixes an issue while using Backlight and External EEPROM at the same time that would cause the MCU to lock up.
* Address wake from sleep instability ([#11450](https://github.com/qmk/qmk_firmware/pull/11450))
* Fix pressing media key on a momentarily activated layer may lead to missing key up events ([#11162](https://github.com/qmk/qmk_firmware/pull/11162))
* Fix an RGB initialisation bug on Massdrop keyboards ([#12022](https://github.com/qmk/qmk_firmware/pull/12022))
* Fix file encoding errors on Windows, and layouts not correctly merging into info.json ([#12039](https://github.com/qmk/qmk_firmware/pull/12039))
### Additions and Enhancements
* Allow configuration of serial USART timeout ([#11057](https://github.com/qmk/qmk_firmware/pull/11057))
* Added Sync Timer feature for Split Common keyboards ([#10997](https://github.com/qmk/qmk_firmware/pull/10997))
* Add modifier state to the Split Common transport ([#10400](https://github.com/qmk/qmk_firmware/pull/10400))
* Add Pix keyboard by sendz (`sendyyeah/pix`) ([#11154](https://github.com/qmk/qmk_firmware/pull/11154))
* Implement option for kinetic mouse movement algorithm for mouse keys ([#6739](https://github.com/qmk/qmk_firmware/pull/6739))
* Improved Language Specific Keycodes for US International and Extended Layouts ([#11307](https://github.com/qmk/qmk_firmware/pull/11307))
* Modified `QWIIC_ENABLE` in `rules.mk` to be yes/no choice, adding `QWIIC_DRIVERS` to allow for inclusion of specific drivers ([#11426](https://github.com/qmk/qmk_firmware/pull/11426))
* Allow AVR-based keyboards to override the `bootloader_jump` function ([#11418](https://github.com/qmk/qmk_firmware/pull/11418))
* Refine RGBLight Twinkle effect to be smoother (use breathing curve) ([#11350](https://github.com/qmk/qmk_firmware/pull/11350))
* Keep track of last matrix activity ([#10730](https://github.com/qmk/qmk_firmware/pull/10730), [`ab375d3`](https://github.com/qmk/qmk_firmware/commit/ab375d3d075c105f09a1ddd0e155f178225518bc), [#11552](https://github.com/qmk/qmk_firmware/pull/11552))
* fix `matrix_io_delay()` timing in `quantum/matrix.c` ([#9603](https://github.com/qmk/qmk_firmware/pull/9603))
* Keep track of encoder activity ([#11595](https://github.com/qmk/qmk_firmware/pull/11595))
* Backport ChibiOS Audio changes from ZSA ([#11687](https://github.com/qmk/qmk_firmware/pull/11687))
* Add support for 8 buttons to mouse report ([#10807](https://github.com/qmk/qmk_firmware/pull/10807))
* Allow `post_config.h` to be implemented in userspace ([#11519](https://github.com/qmk/qmk_firmware/pull/11519))
* Adds AT90USB162 support ([#11570](https://github.com/qmk/qmk_firmware/pull/11570))
* Stop sounds when suspended ([#11553](https://github.com/qmk/qmk_firmware/pull/11553))
* Revamp spidey3 userspace and keymaps ([#11768](https://github.com/qmk/qmk_firmware/pull/11768))
* Add support for analog USBPD on STM32G4xx ([#11824](https://github.com/qmk/qmk_firmware/pull/11824))
* Master matrix can now be transported to the slave side in Split Common keyboards ([#11046](https://github.com/qmk/qmk_firmware/pull/11046))
* Refactor platform logic within `print.h` ([#11863](https://github.com/qmk/qmk_firmware/pull/11863))
* Audio system overhaul ([#11820](https://github.com/qmk/qmk_firmware/pull/11820))
* Output selection: Remove "USB and BT" option for Bluetooth ([#11940](https://github.com/qmk/qmk_firmware/pull/11940))
*`tmk_core/common/action.c`: refactor for code size; merge multiple `case`s into one ([#11943](https://github.com/qmk/qmk_firmware/pull/11943))
* Remove rules and settings from user keymaps that are already defined at keyboard level ([#11966](https://github.com/qmk/qmk_firmware/pull/11966))
### QMK Infrastructure and Internals
* bump to python 3.7 ([#11408](https://github.com/qmk/qmk_firmware/pull/11408))
*`develop` branch is now formatted as part of CI tasks ([#11893](https://github.com/qmk/qmk_firmware/pull/11893), [#11905](https://github.com/qmk/qmk_firmware/pull/11905), [#11907](https://github.com/qmk/qmk_firmware/pull/11907), [#11928](https://github.com/qmk/qmk_firmware/pull/11928), [#11936](https://github.com/qmk/qmk_firmware/pull/11936))
* Configure keyboard matrix from info.json ([#10817](https://github.com/qmk/qmk_firmware/pull/10817))
* Validate our JSON data using json_schema ([#11101](https://github.com/qmk/qmk_firmware/pull/11101))
* Use the schema to eliminate custom code ([#11108](https://github.com/qmk/qmk_firmware/pull/11108))
* Add support for specifying BOARD in `info.json` ([#11492](https://github.com/qmk/qmk_firmware/pull/11492))
* Document how to add data driven configurations ([#11502](https://github.com/qmk/qmk_firmware/pull/11502))
* Process info.json rules ahead of userspace rules ([#11542](https://github.com/qmk/qmk_firmware/pull/11542))
The [Audio feature](feature_audio.md) breaks the hardware specifics out into separate, exchangeable driver units, with a common interface to the audio-"core" - which itself handles playing songs and notes while tracking their progress in an internal state, initializing/starting/stopping the driver as needed.
Not all MCUs support every available driver, either the platform-support is not there (yet?) or the MCU simply does not have the required hardware peripheral.
## AVR :id=avr
Boards built around an Atmega32U4 can use two sets of PWM capable pins, each driving a separate speaker.
The possible configurations are:
| | Timer3 | Timer1 |
|--------------|-------------|--------------|
| one speaker | C4,C5 or C6 | |
| one speaker | | B4, B5 or B7 |
| two speakers | C4,C5 or C6 | B4, B5 or B7 |
Currently there is only one/default driver for AVR based boards, which is automatically configured to:
```make
AUDIO_DRIVER= pwm_hardware
```
## ARM :id=arm
For Arm based boards, QMK depends on ChibiOS - hence any MCU supported by the later is likely usable, as long as certain hardware peripherals are available.
Supported wiring configurations, with their ChibiOS/MCU peripheral requirement are listed below;
piezo speakers are marked with :one: for the first/primary and :two: for the secondary.
| `AUDIO_DAC_SAMPLE_MAX` | `4095U` | Highest value allowed. Lower value means lower volume. And 4095U is the upper limit, since this is limited to a 12 bit value. Only effects non-pregenerated samples. |
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when notplaying anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
| `AUDIO_MAX_SIMULTANEOUS_TONES` | __see next table__ | The number of tones that can be played simultaneously. A value that is too high may freeze the controller or glitch out when too many tones are being played. |
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
There are a number of predefined quality settings that you can use, with "sane minimum" being the default. You can use custom values by simply defining the sample rate and number of simultaneous tones, instead of using one of the listed presets.
This driver uses the ChibiOS-PWM system to produce a square-wave on specific output pins that are connected to the PWM hardware.
The hardware directly toggles the pin via its alternate function. See your MCU's data-sheet for which pin can be driven by what timer - looking for TIMx_CHy and the corresponding alternate function.
A configuration example for the STM32F103C8 would be:
``` c
//halconf.h:
#define HAL_USE_PWM TRUE
#define HAL_USE_PAL TRUE
#define HAL_USE_GPT TRUE
#include_next <halconf.h>
```
``` c
// mcuconf.h:
#include_next <mcuconf.h>
#undef STM32_PWM_USE_TIM1
#define STM32_PWM_USE_TIM1 TRUE
#undef STM32_GPT_USE_TIM4
#define STM32_GPT_USE_TIM4 TRUE
```
If we now target pin A8, looking through the data-sheet of the STM32F103C8, for the timers and alternate functions
- TIM1_CH1 = PA8 <- alternate0
- TIM1_CH2 = PA9
- TIM1_CH3 = PA10
- TIM1_CH4 = PA11
with all this information, the configuration would contain these lines:
``` c
//config.h:
#define AUDIO_PIN A8
#define AUDIO_PWM_DRIVER PWMD1
#define AUDIO_PWM_CHANNEL 1
#define AUDIO_STATE_TIMER GPTD4
```
ChibiOS uses GPIOv1 for the F103, which only knows of one alternate function.
On 'larger' STM32s, GPIOv2 or GPIOv3 are used; with them it is also necessary to configure `AUDIO_PWM_PAL_MODE` to the correct alternate function for the selected pin, timer and timer-channel.
### PWM software :id=pwm-software
This driver uses the PWM callbacks from PWMD1 with TIM1_CH1 to toggle the selected AUDIO_PIN in software.
During the same callback, with AUDIO_PIN_ALT_AS_NEGATIVE set, the AUDIO_PIN_ALT is toggled inversely to AUDIO_PIN. This is useful for setups that drive a piezo from two pins (instead of one and Gnd).
You can also change the timer used for software PWM by defining the driver. For instance:
```c
#define AUDIO_STATE_TIMER GPTD8
```
### Testing Notes :id=testing-notes
While not an exhaustive list, the following table provides the scenarios that have been partially validated:
@@ -67,16 +67,22 @@ This is a C header file that is one of the first things included, and will persi
* turns on the alternate audio voices (to cycle through)
*`#define C4_AUDIO`
* enables audio on pin C4
* Deprecated. Use `#define AUDIO_PIN C4`
*`#define C5_AUDIO`
* enables audio on pin C5
* Deprecated. Use `#define AUDIO_PIN C5`
*`#define C6_AUDIO`
* enables audio on pin C6
* Deprecated. Use `#define AUDIO_PIN C6`
*`#define B5_AUDIO`
* enables audio on pin B5 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
* enables audio on pin B5 (duophony is enabled if one of B pins is enabled along with one of C pins)
* Deprecated. Use `#define AUDIO_PIN B5`, or use `#define AUDIO_PIN_ALT B5` if a `C` pin is enabled with `AUDIO_PIN`
*`#define B6_AUDIO`
* enables audio on pin B6 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
* enables audio on pin B5 (duophony is enabled if one of B pins is enabled along with one of C pins)
* Deprecated. Use `#define AUDIO_PIN B6`, or use `#define AUDIO_PIN_ALT B6` if a `C` pin is enabled with `AUDIO_PIN`
*`#define B7_AUDIO`
* enables audio on pin B7 (duophony is enables if one of B[5-7]\_AUDIO is enabled along with one of C[4-6]\_AUDIO)
* enables audio on pin B5 (duophony is enabled if one of B pins is enabled along with one of C pins)
* Deprecated. Use `#define AUDIO_PIN B7`, or use `#define AUDIO_PIN_ALT B7` if a `C` pin is enabled with `AUDIO_PIN`
*`#define BACKLIGHT_PIN B7`
* pin of the backlight
*`#define BACKLIGHT_LEVELS 3`
@@ -97,6 +103,8 @@ This is a C header file that is one of the first things included, and will persi
* sets the maximum power (in mA) over USB for the device (default: 500)
*`#define USB_POLLING_INTERVAL_MS 10`
* sets the USB polling rate in milliseconds for the keyboard, mouse, and shared (NKRO/media keys) interfaces
*`#define USB_SUSPEND_WAKEUP_DELAY 200`
* set the number of milliseconde to pause after sending a wakeup packet
*`#define F_SCL 100000L`
* sets the I2C clock rate speed for keyboards using I2C. The default is `400000L`, except for keyboards using `split_common`, where the default is `100000L`.
This page describes how QMK's data driven JSON configuration system works. It is aimed at developers who want to work on QMK itself.
## History
Historically QMK has been configured through a combination of two mechanisms- `rules.mk` and `config.h`. While this worked well when QMK was only a handful of keyboards we've grown to encompass nearly 1500 supported keyboards. That extrapolates out to 6000 configuration files under `keyboards/` alone! The freeform nature of these files and the unique patterns people have used to avoid duplication have made ongoing maintenance a challenge, and a large number of our keyboards follow patterns that are outdated and sometimes harder to understand.
We have also been working on bringing the power of QMK to people who aren't comformable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
Now we have support for generating `rules.mk` and `config.h` values from `info.json`, allowing us to have a single source of truth. This will allow us to use automated tooling to maintain keyboards saving a lot of time and maintenance work.
## Overview
On the C side of things nothing changes. When you need to create a new rule or define you follow the same process:
1. Add it to `docs/config_options.md`
1. Set a default in the appropriate core file
1. Add your ifdef statements as needed
You will then need to add support for your new configuration to `info.json`. The basic process is:
1. Add it to the schema in `data/schemas/keyboards.jsonschema`
1. Add a mapping in `data/maps`
1. (optional and discoraged) Add code to extract/generate it to:
*`lib/python/qmk/info.py`
*`lib/python/qmk/cli/generate/config_h.py`
*`lib/python/qmk/cli/generate/rules_mk.py`
## Adding an option to info.json
This section describes adding support for a `config.h`/`rules.mk` value to info.json.
### Add it to the schema
QMK maintains [jsonschema](https://json-schema.org/) files in `data/schemas`. The values that go into keyboard-specific `info.json` files are kept in `keyboard.jsonschema`. Any value you want to make available to end users to edit must go in here.
In some cases you can simply add a new top-level key. Some examples to follow are `keyboard_name`, `maintainer`, `processor`, and `url`. This is appropriate when your option is self-contained and not directly related to other options.
In other cases you should group like options together in an `object`. This is particularly true when adding support for a feature. Some examples to follow for this are `indicators`, `matrix_pins`, and `rgblight`. If you are not sure how to integrate your new option(s) [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and start a conversation there.
### Add a mapping
In most cases you can add a simple mapping. These are maintained as JSON files in `data/mappings/info_config.json` and `data/mappings/info_rules.json`, and control mapping for `config.h` and `rules.mk`, respectively. Each mapping is keyed by the `config.h` or `rules.mk` variable, and the value is a hash with the following keys:
*`info_key`: (required) The location within `info.json` for this value. See below.
*`value_type`: (optional) Default `str`. The format for this variable's value. See below.
*`to_json`: (optional) Default `true`. Set to `false` to exclude this mapping from info.json
*`to_c`: (optional) Default `true`. Set to `false` to exclude this mapping from config.h
*`warn_duplicate`: (optional) Default `true`. Set to `false` to turn off warning when a value exists in both places
#### Info Key
We use JSON dot notation to address variables within info.json. For example, to access `info_json["rgblight"]["split_count"]` I would specify `rgblight.split_count`. This allows you to address deeply nested keys with a simple string.
Under the hood we use [Dotty Dict](https://dotty-dict.readthedocs.io/en/latest/), you can refer to that documentation for how these strings are converted to object access.
#### Value Types
By default we treat all values as simple strings. If your value is more complex you can use one of these types to intelligently parse the data:
*`array`: A comma separated array of strings
*`array.int`: A comma separated array of integers
*`int`: An integer
*`hex`: A number formatted as hex
*`list`: A space separate array of strings
*`mapping`: A hash of key/value pairs
### Add code to extract it
Most use cases can be solved by the mapping files described above. If yours can't you can instead write code to extract your config values.
Whenever QMK generates a complete `info.json` it extracts information from `config.h` and `rules.mk`. You will need to add code for your new config value to `lib/python/qmk/info.py`. Typically this means adding a new `_extract_<feature>()` function and then calling your function in either `_extract_config_h()` or `_extract_rules_mk()`.
If you are not sure how to edit this file or are not comfortable with Python [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and someone can help you with this part.
### Add code to generate it
The final piece of the puzzle is providing your new option to the build system. This is done by generating two files:
*`.build/obj_<keyboard>/src/info_config.h`
*`.build/obj_<keyboard>/src/rules.mk`
These two files are generated by the code here:
*`lib/python/qmk/cli/generate/config_h.py`
*`lib/python/qmk/cli/generate/rules_mk.py`
For `config.h` values you'll need to write a function for your rule(s) and call that function in `generate_config_h()`.
If you have a new top-level `info.json` key for `rules.mk` you can simply add your keys to `info_to_rules` at the top of `lib/python/qmk/cli/generate/rules_mk.py`. Otherwise you'll need to create a new if block for your feature in `generate_rules_mk()`.
@@ -23,6 +23,141 @@ These allow you to combine a modifier with a keycode. When pressed, the keydown
You can also chain them, for example `LCTL(LALT(KC_DEL))` or `C(A(KC_DEL))` makes a key that sends Control+Alt+Delete with a single keypress.
# Checking Modifier State :id=checking-modifier-state
The current modifier state can mainly be accessed with two functions: `get_mods()` for normal modifiers and modtaps and `get_oneshot_mods()` for one-shot modifiers (unless they're held, in which case they act like normal modifier keys).
The presence of one or more specific modifiers in the current modifier state can be detected by ANDing the modifier state with a mod mask corresponding to the set of modifiers you want to match for. The reason why bitwise operators are used is that the modifier state is stored as a single byte in the format (GASC)<sub>R</sub>(GASC)<sub>L</sub>.
Thus, to give an example, `01000010` would be the internal representation of LShift+RAlt.
For more information on bitwise operators in C, click [here](https://en.wikipedia.org/wiki/Bitwise_operations_in_C) to open the Wikipedia page on the topic.
In practice, this means that you can check whether a given modifier is active with `get_mods() & MOD_BIT(KC_<modifier>)` (see the [list of modifier keycodes](keycodes_basic.md#modifiers)) or with `get_mods() & MOD_MASK_<modifier>` if the difference between left and right hand modifiers is not important and you want to match both. Same thing can be done for one-shot modifiers if you replace `get_mods()` with `get_oneshot_mods()`.
To check that *only* a specific set of mods is active at a time, AND the modifier state and your desired mod mask as explained above and compare the result to the mod mask itself: `get_mods() & <mod mask> == <mod mask>`.
For example, let's say you want to trigger a piece of custom code if one-shot left control and one-shot left shift are on but every other one-shot mods are off. To do so, you can compose the desired mod mask by combining the mod bits for left control and shift with `(MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))` and then plug it in: `get_oneshot_mods & (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT)) == (MOD_BIT(KC_LCTL) | MOD_BIT(KC_LSFT))`. Using `MOD_MASK_CS` instead for the mod bitmask would have forced you to press four modifier keys (both versions of control and shift) to fulfill the condition.
Aside from accessing the currently active modifiers using `get_mods()`, there exists some other functions you can use to modify the modifier state, where the `mods` argument refers to the modifiers bitmask.
*`add_mods(mods)`: Enable `mods` without affecting any other modifiers
*`register_mods(mods)`: Like `add_mods` but send a keyboard report immediately.
*`del_mods(mods)`: Disable `mods` without affecting any other modifiers
*`unregister_mods(mods)`: Like `del_mods` but send a keyboard report immediately.
*`set_mods(mods)`: Overwrite current modifier state with `mods`
*`clear_mods()`: Reset the modifier state by disabling all modifiers
Similarly, in addition to `get_oneshot_mods()`, there also exists these functions for one-shot mods:
*`add_oneshot_mods(mods)`: Enable `mods` without affecting any other one-shot modifiers
*`del_oneshot_mods(mods)`: Disable `mods` without affecting any other one-shot modifiers
*`set_oneshot_mods(mods)`: Overwrite current one-shot modifier state with `mods`
*`clear_oneshot_mods()`: Reset the one-shot modifier state by disabling all one-shot modifiers
## Examples :id=examples
The following examples use [advanced macro functions](feature_macros.md#advanced-macro-functions) which you can read more about in the [documentation page on macros](feature_macros.md).
### Alt + Escape for Alt + Tab :id=alt-escape-for-alt-tab
Simple example where chording Left Alt with `KC_ESC` makes it behave like `KC_TAB` for alt-tabbing between applications. This example strictly checks if only Left Alt is active, meaning you can't do Alt+Shift+Esc to switch between applications in reverse order. Also keep in mind that this removes the ability to trigger the actual Alt+Escape keyboard shortcut, though it keeps the ability to do AltGr+Escape.
// No need to register KC_LALT because it's already active.
// The Alt modifier will apply on this KC_TAB.
register_code(KC_TAB);
}else{
unregister_code(KC_TAB);
}
// Do not let QMK process the keycode further
returnfalse;
}
// Else, let QMK process the KC_ESC keycode as usual
returntrue;
}
returntrue;
};
```
### Shift + Backspace for Delete :id=shift-backspace-for-delete
Advanced example where the original behaviour of shift is cancelled when chorded with `KC_BSPC` and is instead fully replaced by `KC_DEL`. Two main variables are created to make this work well: `mod_state` and `delkey_registered`. The first one stores the modifier state and is used to restore it after registering `KC_DEL`. The second variable is a boolean variable (true or false) which keeps track of the status of `KC_DEL` to manage the release of the whole Backspace/Delete key correctly.
As opposed to the previous example, this doesn't use strict modifier checking. Pressing `KC_BSPC` while one or two shifts are active is enough to trigger this custom code, regardless of the state of other modifiers. That approach offers some perks: Ctrl+Shift+Backspace lets us delete the next word (Ctrl+Delete) and Ctrl+Alt+Shift+Backspace lets us execute the Ctrl+Alt+Del keyboard shortcut.
// Store the current modifier state in the variable for later reference
mod_state=get_mods();
switch(keycode){
caseKC_BSPC:
{
// Initialize a boolean variable that keeps track
// of the delete key status: registered or not?
staticbooldelkey_registered;
if(record->event.pressed){
// Detect the activation of either shift keys
if(mod_state&MOD_MASK_SHIFT){
// First temporarily canceling both shifts so that
// shift isn't applied to the KC_DEL keycode
del_mods(MOD_MASK_SHIFT);
register_code(KC_DEL);
// Update the boolean variable to reflect the status of KC_DEL
delkey_registered=true;
// Reapplying modifier state so that the held shift key(s)
// still work even after having tapped the Backspace/Delete key.
set_mods(mod_state);
returnfalse;
}
}else{// on release of KC_BSPC
// In case KC_DEL is still being sent even after the release of KC_BSPC
if(delkey_registered){
unregister_code(KC_DEL);
delkey_registered=false;
returnfalse;
}
}
// Let QMK process the KC_BSPC keycode as usual outside of shift
returntrue;
}
}
returntrue;
};
```
# Legacy Content :id=legacy-content
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
Your keyboard can make sounds! If you've got a Planck, Preonic, or basically any AVR keyboard that allows access to certain PWM-capable pins, you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
Your keyboard can make sounds! If you've got a spare pin you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
Up to two simultaneous audio voices are supported, one driven by timer 1 and another driven by timer 3. The following pins can be defined as audio outputs in config.h:
To activate this feature, add `AUDIO_ENABLE = yes` to your `rules.mk`.
Timer 1:
`#define B5_AUDIO`
`#define B6_AUDIO`
`#define B7_AUDIO`
## AVR based boards
On Atmega32U4 based boards, up to two simultaneous tones can be rendered.
With one speaker connected to a PWM capable pin on PORTC driven by timer 3 and the other on one of the PWM pins on PORTB driven by timer 1.
Timer 3:
`#define C4_AUDIO`
`#define C5_AUDIO`
`#define C6_AUDIO`
The following pins can be configured as audio outputs in `config.h` - for one speaker set eiter one out of:
If you add `AUDIO_ENABLE = yes` to your `rules.mk`, there's a couple different sounds that will automatically be enabled without any other configuration:
*`#define AUDIO_PIN C4`
*`#define AUDIO_PIN C5`
*`#define AUDIO_PIN C6`
*`#define AUDIO_PIN B5`
*`#define AUDIO_PIN B6`
*`#define AUDIO_PIN B7`
and *optionally*, for a second speaker, one of:
*`#define AUDIO_PIN_ALT B5`
*`#define AUDIO_PIN_ALT B6`
*`#define AUDIO_PIN_ALT B7`
### Wiring
per speaker is - for example with a piezo buzzer - the black lead to Ground, and the red lead connected to the selected AUDIO_PIN for the primary; and similarly with AUDIO_PIN_ALT for the secondary.
## ARM based boards
for more technical details, see the notes on [Audio driver](audio_driver.md).
<!-- because I'm not sure where to fit this in: https://waveeditonline.com/ -->
### DAC (basic)
Most STM32 MCUs have DAC peripherals, with a notable exception of the STM32F1xx series. Generally, the DAC peripheral drives pins A4 or A5. To enable DAC-based audio output on STM32 devices, add `AUDIO_DRIVER = dac_basic` to `rules.mk` and set in `config.h` either:
`#define AUDIO_PIN A4` or `#define AUDIO_PIN A5`
the other DAC channel can optionally be used with a secondary speaker, just set:
`#define AUDIO_PIN_ALT A4` or `#define AUDIO_PIN_ALT A5`
Do note though that the dac_basic driver is only capable of reproducing one tone per speaker/channel at a time, for more tones simultaneously, try the dac_additive driver.
#### Wiring:
for two piezos, for example configured as `AUDIO_PIN A4` and `AUDIO_PIN_ALT A5` would be: red lead to A4 and black to Ground, and similarly with the second one: A5 = red, and Ground = black
another alternative is to drive *one* piezo with both DAC pins - for an extra "push".
wiring red to A4 and black to A5 (or the other way round) and add `#define AUDIO_PIN_ALT_AS_NEGATIVE` to `config.h`
##### Proton-C Example:
The Proton-C comes (optionally) with one 'builtin' piezo, which is wired to A4+A5.
For this board `config.h` would include these defines:
```c
#define AUDIO_PIN A5
#define AUDIO_PIN_ALT A4
#define AUDIO_PIN_ALT_AS_NEGATIVE
```
### DAC (additive)
Another option, besides dac_basic (which produces sound through a square-wave), is to use the DAC to do additive wave synthesis.
With a number of predefined wave-forms or by providing your own implementation to generate samples on the fly.
To use this feature set `AUDIO_DRIVER = dac_additive` in your `rules.mk`, and select in `config.h` EITHER `#define AUDIO_PIN A4` or `#define AUDIO_PIN A5`.
The used waveform *defaults* to sine, but others can be selected by adding one of the following defines to `config.h`:
*`#define AUDIO_DAC_SAMPLE_WAVEFORM_SINE`
*`#define AUDIO_DAC_SAMPLE_WAVEFORM_TRIANGLE`
*`#define AUDIO_DAC_SAMPLE_WAVEFORM_TRAPEZOID`
*`#define AUDIO_DAC_SAMPLE_WAVEFORM_SQUARE`
Should you rather choose to generate and use your own sample-table with the DAC unit, implement `uint16_t dac_value_generate(void)` with your keyboard - for an example implementation see keyboards/planck/keymaps/synth_sample or keyboards/planck/keymaps/synth_wavetable
### PWM (software)
if the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
Note that there is currently only one speaker/pin supported.
set in `rules.mk`:
`AUDIO_DRIVER = pwm_software` and in `config.h`:
`#define AUDIO_PIN C13` (can be any pin) to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
#### Wiring
the usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
OR if you can chose to drive one piezo with two pins, for example `#define AUDIO_PIN B1`, `#define AUDIO_PIN_ALT B2` in `config.h`, with `#define AUDIO_PIN_ALT_AS_NEGATIVE` - then the red lead could go to B1, the black to B2.
### PWM (hardware)
STM32F1xx have to fall back to using PWM, but can do so in hardware; but again on currently only one speaker/pin.
`AUDIO_DRIVER = pwm_hardware` in `rules.mk`, and in `config.h`:
`#define AUDIO_PIN A8`
`#define AUDIO_PWM_DRIVER PWMD1`
`#define AUDIO_PWM_CHANNEL 1`
(as well as `#define AUDIO_PWM_PAL_MODE 42` if you are on STM32F2 or larger)
which will use Timer 1 to directly drive pin PA8 through the PWM hardware (TIM1_CH1 = PA8).
Should you want to use the pwm-hardware on another pin and timer - be ready to dig into the STM32 data-sheet to pick the right TIMx_CHy and pin-alternate function.
## Tone Multiplexing
Since most drivers can only render one tone per speaker at a time (with the one exception: arm dac-additive) there also exists a "workaround-feature" that does time-slicing/multiplexing - which does what the name implies: cycle through a set of active tones (e.g. when playing chords in Music Mode) at a given rate, and put one tone at a time out through the one/few speakers that are available.
To enable this feature, and configure a starting-rate, add the following defines to `config.h`:
```c
#define AUDIO_ENABLE_TONE_MULTIPLEXING
#define AUDIO_TONE_MULTIPLEXING_RATE_DEFAULT 10
```
The audio core offers interface functions to get/set/change the tone multiplexing rate from within `keymap.c`.
## Songs
There's a couple of different sounds that will automatically be enabled without any other configuration:
```
STARTUP_SONG // plays when the keyboard starts up (audio.c)
GOODBYE_SONG // plays when you press the RESET key (quantum.c)
@@ -67,15 +163,34 @@ The available keycodes for audio are:
*`AU_OFF` - Turn Audio Feature off
*`AU_TOG` - Toggle Audio Feature state
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
## Tempo
the 'speed' at which SONGs are played is dictated by the set Tempo, which is measured in beats-per-minute. Note lenghts are defined relative to that.
The initial/default tempo is set to 120 bpm, but can be configured by setting `TEMPO_DEFAULT` in `config.c`.
There is also a set of functions to modify the tempo from within the user/keymap code:
```c
voidaudio_set_tempo(uint8_ttempo);
voidaudio_increase_tempo(uint8_ttempo_change);
voidaudio_decrease_tempo(uint8_ttempo_change);
```
## ARM Audio Volume
For ARM devices, you can adjust the DAC sample values. If your board is too loud for you or your coworkers, you can set the max using `DAC_SAMPLE_MAX` in your `config.h`:
For ARM devices, you can adjust the DAC sample values. If your board is too loud for you or your coworkers, you can set the max using `AUDIO_DAC_SAMPLE_MAX` in your `config.h`:
```c
#define DAC_SAMPLE_MAX 65535U
#define AUDIO_DAC_SAMPLE_MAX 4095U
```
the DAC usually runs in 12Bit mode, hence a volume of 100% = 4095U
Note: this only adjusts the volume aka 'works' if you stick to WAVEFORM_SQUARE, since its samples are generated on the fly - any other waveform uses a hardcoded/precomputed sample-buffer.
## Voices
Aka "audio effects", different ones can be enabled by setting in `config.h` these defines:
`#define AUDIO_VOICES` to enable the feature, and `#define AUDIO_VOICE_DEFAULT something` to select a specific effect
for details see quantum/audio/voices.h and .c
## Music Mode
@@ -215,12 +330,6 @@ This is still a WIP, but check out `quantum/process_keycode/process_midi.c` to s
@@ -39,7 +39,7 @@ Not all keycodes below will work depending on which haptic mechanism you have ch
First you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
[Wiring diagram provided by Adafruit](https://playground.arduino.cc/uploads/Learning/solenoid_driver.pdf)
[Wiring diagram provided by Adafruit](https://cdn-shop.adafruit.com/product-files/412/solenoid_driver.pdf)
@@ -10,9 +10,11 @@ If you want to use RGB LED's you should use the [RGB Matrix Subsystem](feature_r
There is basic support for addressable LED matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`:
LED_MATRIX_ENABLE = yes
LED_MATRIX_DRIVER = IS31FL3731
```make
LED_MATRIX_ENABLE= yes
LED_MATRIX_DRIVER= IS31FL3731
```
You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_<N>` defines for IC's that are not present on your keyboard. You can define the following items in `config.h`:
| Variable | Description | Default |
@@ -20,7 +22,7 @@ You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_<N>
| `ISSI_TIMEOUT` | (Optional) How long to wait for i2c messages | 100 |
| `ISSI_PERSISTENCE` | (Optional) Retry failed messages this many times | 0 |
| `LED_DRIVER_COUNT` | (Required) How many LED driver IC's are present | |
| `LED_DRIVER_LED_COUNT` | (Required) How many LED lights are present across all drivers | |
| `DRIVER_LED_TOTAL` | (Required) How many LED lights are present across all drivers | |
| `LED_DRIVER_ADDR_1` | (Required) Address for the first LED driver | |
| `LED_DRIVER_ADDR_2` | (Optional) Address for the second LED driver | |
| `LED_DRIVER_ADDR_3` | (Optional) Address for the third LED driver | |
@@ -28,33 +30,38 @@ You can use between 1 and 4 IS31FL3731 IC's. Do not specify `LED_DRIVER_ADDR_<N>
Here is an example using 2 drivers.
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
// 0b1110100 AD <-> GND
// 0b1110111 AD <-> VCC
// 0b1110101 AD <-> SCL
// 0b1110110 AD <-> SDA
#define LED_DRIVER_ADDR_1 0b1110100
#define LED_DRIVER_ADDR_2 0b1110110
```c
// This is a 7-bit address, that gets left-shifted and bit 0
// set to 0 for write, 1 for read (as per I2C protocol)
// The address will vary depending on your wiring:
Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations.
Define these arrays listing all the LEDs in your `<keyboard>.c`:
const is31_led g_is31_leds[DRIVER_LED_TOTAL] = {
/* Refer to IS31 manual for these locations
* driver
*|LED address
* | | */
{0, C3_3},
....
}
```c
constis31_ledg_is31_leds[DRIVER_LED_TOTAL]={
/* Refer to IS31 manual for these locations
* driver
* | LED address
* | | */
{0,C1_1},
{0,C1_15},
// ...
}
```
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731-simple.h`. The `driver` is the index of the driver you defined in your `config.h` (`0`, `1`, `2`, or `3` ).
@@ -66,26 +73,28 @@ All LED matrix keycodes are currently shared with the [backlight system](feature
Currently no LED matrix effects have been created.
## Custom layer effects
## Custom Layer Effects
Custom layer effects can be done by defining this in your `<keyboard>.c`:
void led_matrix_indicators_kb(void) {
led_matrix_set_index_value(index, value);
}
```c
voidled_matrix_indicators_kb(void){
led_matrix_set_index_value(index,value);
}
```
A similar function works in the keymap as `led_matrix_indicators_user`.
## Suspended state
## Suspended State
To use the suspend feature, add this to your `<keyboard>.c`:
@@ -4,7 +4,7 @@ Macros allow you to send multiple keystrokes when pressing just one key. QMK has
!> **Security Note**: While it is possible to use macros to send passwords, credit card numbers, and other sensitive information it is a supremely bad idea to do so. Anyone who gets a hold of your keyboard will be able to access that information by opening a text editor.
## The New Way: `SEND_STRING()` & `process_record_user`
## `SEND_STRING()` & `process_record_user`
Sometimes you want a key to type out words or phrases. For the most common situations, we've provided `SEND_STRING()`, which will type out a string (i.e. a sequence of characters) for you. All ASCII characters that are easily translatable to a keycode are supported (e.g. `qmk 123\n\t`).
There are some functions you may find useful in macro-writing. Keep in mind that while you can write some fairly advanced code within a macro, if your functionality gets too complex you may want to define a custom keycode instead. Macros are meant to be simple.
?> You can also use the functions described in [Useful functions](ref_functions.md) for additional functionality. For example `reset_keyboard()` allows you to reset the keyboard as part of a macro.
?> You can also use the functions described in [Useful function](ref_functions.md) and [Checking modifier state](feature_advanced_keycodes#checking-modifier-state) for additional functionality. For example,`reset_keyboard()` allows you to reset the keyboard as part of a macro and `get_mods() & MOD_MASK_SHIFT` lets you check for the existence of active shift modifiers.
### `record->event.pressed`
@@ -233,9 +233,15 @@ Parallel to `register_code` function, this sends the `<kc>` keyup event to the c
### `tap_code(<kc>);`
This will send `register_code(<kc>)` and then `unregister_code(<kc>)`. This is useful if you want to send both the press and release events ("tap" the key, rather than hold it).
Sends`register_code(<kc>)` and then `unregister_code(<kc>)`. This is useful if you want to send both the press and release events ("tap" the key, rather than hold it).
If you're having issues with taps (un)registering, you can add a delay between the register and unregister events by setting `#define TAP_CODE_DELAY 100` in your `config.h` file. The value is in milliseconds.
If `TAP_CODE_DELAY` is defined (default 0), this function waits that many milliseconds before calling `unregister_code(<kc>)`. This can be useful when you are having issues with taps (un)registering.
If the keycode is `KC_CAPS`, it waits `TAP_HOLD_CAPS_DELAY` milliseconds instead (default 80), as macOS prevents accidental Caps Lock activation by waiting for the key to be held for a certain amount of time.
### `tap_code_delay(<kc>, <delay>);`
Like `tap_code(<kc>)`, but with a `delay` parameter for specifying arbitrary intervals before sending the unregister event.
### `register_code16(<kc>);`, `unregister_code16(<kc>);` and `tap_code16(<kc>);`
@@ -262,15 +268,15 @@ This will clear all keys besides the mods currently pressed.
This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
```c
boolis_alt_tab_active=false;#ADD this near thebeginingofkeymap.c
uint16_talt_tab_timer=0;#wewillbe using them soon.
boolis_alt_tab_active=false;// ADD thisnear the begining of keymap.c
uint16_talt_tab_timer=0;// we will be usingthemsoon.
enumcustom_keycodes{# Make sure have the awesome keycode ready
enumcustom_keycodes{// Makesurehave the awesomekeycodeready
This defines two macros which will be run when the key they are assigned to is pressed. If instead you'd like them to run when the key is released you can change the if statement:
if (!record->event.pressed) {
### Macro Commands
A macro can include the following commands:
* I() change interval of stroke in milliseconds.
* D() press key.
* U() release key.
* T() type key(press and release).
* W() wait (milliseconds).
* END end mark.
### Mapping a Macro to a Key
Use the `M()` function within your keymap to call a macro. For example, here is the keymap for a 2-key keyboard:
When you press the key on the left it will type "Hi!" and when you press the key on the right it will type "Bye!".
### Naming Your Macros
If you have a bunch of macros you want to refer to from your keymap while keeping the keymap easily readable you can name them using `#define` at the top of your file.
@@ -29,6 +29,9 @@ In your keymap you can use the following keycodes to map key presses to mouse ac
|`KC_MS_BTN3` |`KC_BTN3`|Press button 3 |
|`KC_MS_BTN4` |`KC_BTN4`|Press button 4 |
|`KC_MS_BTN5` |`KC_BTN5`|Press button 5 |
|`KC_MS_BTN6` |`KC_BTN6`|Press button 6 |
|`KC_MS_BTN7` |`KC_BTN7`|Press button 7 |
|`KC_MS_BTN8` |`KC_BTN8`|Press button 8 |
|`KC_MS_WH_UP` |`KC_WH_U`|Move wheel up |
|`KC_MS_WH_DOWN` |`KC_WH_D`|Move wheel down |
|`KC_MS_WH_LEFT` |`KC_WH_L`|Move wheel left |
@@ -42,6 +45,7 @@ In your keymap you can use the following keycodes to map key presses to mouse ac
Mouse keys supports three different modes to move the cursor:
* **Accelerated (default):** Holding movement keys accelerates the cursor until it reaches its maximum speed.
* **Kinetic:** Holding movement keys accelerates the cursor with its speed following a quadratic curve until it reaches its maximum speed.
* **Constant:** Holding movement keys moves the cursor at constant speeds.
* **Combined:** Holding movement keys accelerates the cursor until it reaches its maximum speed, but holding acceleration and movement keys simultaneously moves the cursor at constant speeds.
@@ -56,7 +60,8 @@ This is the default mode. You can adjust the cursor and scrolling acceleration u
|`MOUSEKEY_DELAY` |300 |Delay between pressing a movement key and cursor movement|
|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements |
|`MOUSEKEY_INTERVAL` |50 |Time between cursor movements in milliseconds |
|`MOUSEKEY_MOVE_DELTA` |5 |Step size |
|`MOUSEKEY_MAX_SPEED` |10 |Maximum cursor speed at which acceleration stops |
|`MOUSEKEY_TIME_TO_MAX` |20 |Time until maximum cursor speed is reached |
|`MOUSEKEY_WHEEL_DELAY` |300 |Delay between pressing a wheel key and wheel movement |
@@ -73,6 +78,30 @@ Tips:
Cursor acceleration uses the same algorithm as the X Window System MouseKeysAccel feature. You can read more about it [on Wikipedia](https://en.wikipedia.org/wiki/Mouse_keys).
### Kinetic Mode
This is an extension of the accelerated mode. The kinetic mode uses a quadratic curve on the cursor speed which allows precise movements at the beginning and allows to cover large distances by increasing cursor speed quickly thereafter. You can adjust the cursor and scrolling acceleration using the following settings in your keymap’s `config.h` file:
* The smoothness of the cursor movement depends on the `MOUSEKEY_INTERVAL` setting. The shorter the interval is set the smoother the movement will be. Setting the value too low makes the cursor unresponsive. Lower settings are possible if the micro processor is fast enough. For example: At an interval of `8` milliseconds, `125` movements per second will be initiated. With a base speed of `1000` each movement will move the cursor by `8` pixels.
* Mouse wheel movements are implemented differently from cursor movements. While it's okay for the cursor to move multiple pixels at once for the mouse wheel this would lead to jerky movements. Instead, the mouse wheel operates at step size `1`. Setting mouse wheel speed is done by adjusting the number of wheel movements per second.
### Constant mode
In this mode you can define multiple different speeds for both the cursor and the mouse wheel. There is no acceleration. `KC_ACL0`, `KC_ACL1` and `KC_ACL2` change the cursor and scroll speed to their respective setting.
@@ -19,7 +19,7 @@ Keep in mind that a report_mouse_t (here "mouseReport") has the following proper
*`mouseReport.y` - this is a signed int from -127 to 127 (not 128, this is defined in USB HID spec) representing movement (+ upward, - downward) on the y axis.
*`mouseReport.v` - this is a signed int from -127 to 127 (not 128, this is defined in USB HID spec) representing vertical scrolling (+ upward, - downward).
*`mouseReport.h` - this is a signed int from -127 to 127 (not 128, this is defined in USB HID spec) representing horizontal scrolling (+ right, - left).
*`mouseReport.buttons` - this is a uint8_t in which the last 5 bits are used. These bits represent the mouse button state - bit 3 is mouse button 5, and bit 7 is mouse button 1.
*`mouseReport.buttons` - this is a uint8_t in which all 8 bits are used. These bits represent the mouse button state - bit 0 is mouse button 1, and bit 7 is mouse button 8.
Once you have made the necessary changes to the mouse report, you need to send it:
@@ -129,6 +129,28 @@ Configure the hardware via your `config.h`:
---
### APA102 :id=apa102
There is basic support for APA102 based addressable LED strands. To enable it, add this to your `rules.mk`:
```makefile
RGB_MATRIX_ENABLE= yes
RGB_MATRIX_DRIVER= APA102
```
Configure the hardware via your `config.h`:
```c
// The pin connected to the data pin of the LEDs
#define RGB_DI_PIN D7
// The pin connected to the clock pin of the LEDs
#define RGB_CI_PIN D6
// The number of LEDs connected
#define DRIVER_LED_TOTAL 70
```
---
From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
@@ -10,6 +10,7 @@ Currently QMK supports the following addressable LEDs (however, the white LED in
* WS2811, WS2812, WS2812B, WS2812C, etc.
* SK6812, SK6812MINI, SK6805
* APA102
These LEDs are called "addressable" because instead of using a wire per color, each LED contains a small microchip that understands a special protocol sent over a single wire. The chip passes on the remaining data to the next LED, allowing them to be chained together. In this way, you can easily control the color of the individual LEDs.
@@ -21,11 +22,19 @@ On keyboards with onboard RGB LEDs, it is usually enabled by default. If it is n
RGBLIGHT_ENABLE= yes
```
At minimum you must define the data pin your LED strip is connected to, and the number of LEDs in the strip, in your `config.h`. If your keyboard has onboard RGB LEDs, and you are simply creating a keymap, you usually won't need to modify these.
For APA102 LEDs, add the following to your `rules.mk`:
```make
RGBLIGHT_ENABLE= yes
RGBLIGHT_DRIVER= APA102
```
At minimum you must define the data pin your LED strip is connected to, and the number of LEDs in the strip, in your `config.h`. For APA102 LEDs, you must also define the clock pin. If your keyboard has onboard RGB LEDs, and you are simply creating a keymap, you usually won't need to modify these.
|`RGBLIGHT_HUE_STEP` |`10` |The number of steps to cycle through the hue by |
|`RGBLIGHT_SAT_STEP` |`17` |The number of steps to increment the saturation by |
|`RGBLIGHT_VAL_STEP` |`17` |The number of steps to increment the brightness by |
|`RGBLIGHT_LIMIT_VAL` |`255` |The maximum brightness level |
|`RGBLIGHT_SLEEP` |*Not defined*|If defined, the RGB lighting will be switched off when the host goes to sleep|
|`RGBLIGHT_SPLIT` |*Not defined*|If defined, synchronization functionality for split keyboards is added|
|`RGBLIGHT_DISABLE_KEYCODES`|*not defined*|If defined, disables the ability to control RGB Light from the keycodes. You must use code functions to control the feature|
|`RGBLIGHT_HUE_STEP` |`10` |The number of steps to cycle through the hue by |
|`RGBLIGHT_SAT_STEP` |`17` |The number of steps to increment the saturation by |
|`RGBLIGHT_VAL_STEP` |`17` |The number of steps to increment the brightness by |
|`RGBLIGHT_LIMIT_VAL` |`255` |The maximum brightness level |
|`RGBLIGHT_SLEEP` |*Not defined*|If defined, the RGB lighting will be switched off when the host goes to sleep|
|`RGBLIGHT_SPLIT` |*Not defined*|If defined, synchronization functionality for split keyboards is added|
|`RGBLIGHT_DISABLE_KEYCODES`|*Not defined*|If defined, disables the ability to control RGB Light from the keycodes. You must use code functions to control the feature|
|`RGBLIGHT_DEFAULT_MODE` |`RGBLIGHT_MODE_STATIC_LIGHT`|The default mode to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_HUE` |`0` (red) |The default hue to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_SAT` |`UINT8_MAX` (255) |The default saturation to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_VAL` |`RGBLIGHT_LIMIT_VAL` |The default value (brightness) to use upon clearing the EEPROM |
|`RGBLIGHT_DEFAULT_SPD` |`0` |The default speed to use upon clearing the EEPROM |
## Effects and Animations
@@ -139,7 +153,7 @@ The following options are used to tweak the various animations:
|`RGBLIGHT_EFFECT_KNIGHT_OFFSET` |`0` |The number of LEDs to start the "Knight" animation from the start of the strip by |
|`RGBLIGHT_RAINBOW_SWIRL_RANGE` |`255` |Range adjustment for the rainbow swirl effect to get different swirls |
|`RGBLIGHT_EFFECT_SNAKE_LENGTH` |`4` |The number of LEDs to light up for the "Snake" animation |
|`RGBLIGHT_EFFECT_TWINKLE_LIFE` |`75` |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps) |
|`RGBLIGHT_EFFECT_TWINKLE_LIFE` |`200` |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps) |
|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127` |Adjusts how likely each LED is to twinkle (on each animation step) |
@@ -181,6 +181,22 @@ If you're having issues with serial communication, you can change this value, as
* **`4`**: about 26kbps
* **`5`**: about 20kbps
```c
#define SPLIT_MODS_ENABLE
```
This enables transmitting modifier state (normal, weak and oneshot) to the non
primary side of the split keyboard. This adds a few bytes of data to the split
communication protocol and may impact the matrix scan speed when enabled.
The purpose of this feature is to support cosmetic use of modifer state (e.g.
displaying status on an OLED screen).
```c
#define SPLIT_TRANSPORT_MIRROR
```
This mirrors the master side matrix to the slave side for features that react or require knowledge of master side key presses on the slave side. This adds a few bytes of data to the split communication protocol and may impact the matrix scan speed when enabled. The purpose of this feature is to support cosmetic use of key events (e.g. RGB reacting to Keypresses).
### Hardware Configuration Options
There are some settings that you may need to configure, based on how the hardware is set up.
@@ -126,6 +126,8 @@ The following input modes are available:
Enabled by default and works almost anywhere on IBus-enabled distros. Without IBus, this mode works under GTK apps, but rarely anywhere else.
By default, this mode uses Ctrl+Shift+U (`LCTL(LSFT(KC_U))`) to start Unicode input, but this can be changed by defining [`UNICODE_KEY_LNX`](#input-key-configuration) with a different keycode. This might be required for IBus versions ≥1.5.15, where Ctrl+Shift+U behavior is consolidated into Ctrl+Shift+E.
Users who wish support in non-GTK apps without IBus may need to resort to a more indirect method, such as creating a custom keyboard layout ([more on this method](#custom-linux-layout)).
* **`UC_WIN`**: _(not recommended)_ Windows built-in hex numpad Unicode input. Supports code points up to `0xFFFF`.
To enable, create a registry key under `HKEY_CURRENT_USER\Control Panel\Input Method` of type `REG_SZ` called `EnableHexNumpad` and set its value to `1`. This can be done from the Command Prompt by running `reg add "HKCU\Control Panel\Input Method" -v EnableHexNumpad -t REG_SZ -d 1` with administrator privileges. Reboot afterwards.
@@ -270,3 +272,22 @@ AutoHotkey inserts the Text right of `Send, ` when this combination is pressed.
If you enable the US International layout on the system, it will use punctuation to accent the characters. For instance, typing "\`a" will result in à.
You can find details on how to enable this [here](https://support.microsoft.com/en-us/help/17424/windows-change-keyboard-layout).
## Software keyboard layout on Linux :id=custom-linux-layout
This method does not require Unicode support on the keyboard itself but instead uses a custom keyboard layout for Xorg. This is how special characters are inserted by regular keyboards. This does not require IBus and works in practically all software. Help on creating a custom layout can be found [here](https://www.linux.com/news/creating-custom-keyboard-layouts-x11-using-xkb/), [here](http://karols.github.io/blog/2013/11/18/creating-custom-keyboard-layouts-for-linux/) and [here](https://wiki.archlinux.org/index.php/X_keyboard_extension). An example of how you could edit the `us` layout to gain 🤣 on `RALT(KC_R)`:
Edit the keyboard layout file `/usr/share/X11/xkb/symbols/us`.
Find the line defining the R key and add an entry to the list, making it look like this:
```
key <AD04> { [ r, R, U1F923 ] };
```
Save the file and run the command `setxkbmap us` to reload the layout.
You can define one custom character for key defined in the layout, and another if you populate the fourth layer. Additional layers up to 8th are also possible.
This method is specific to the computer on which you set the custom layout. The custom keys will be available only when Xorg is running. To avoid accidents, you should always reload the layout using `setxkbmap`, otherwise an invalid layout could prevent you from logging into your system, locking you out.
@@ -121,10 +121,6 @@ For further details, as well as limitations, see the [Unicode page](feature_unic
This allows you output audio on the C6 pin (needs abstracting). See the [audio page](feature_audio.md) for more information.
`FAUXCLICKY_ENABLE`
Uses buzzer to emulate clicky switches. A cheap imitation of the Cherry blue switches. By default, uses the C6 pin, same as `AUDIO_ENABLE`.
`VARIABLE_TRACE`
Use this to debug changes to variable values, see the [tracing variables](unit_testing.md#tracing-variables) section of the Unit Testing page for more information.
* **`UC_WINC`**: [WinCompose](https://github.com/samhocevar/wincompose) を使った Windows Unicode 入力。v0.9.0 の時点で、`0x10FFFF` までのコードポイント(全ての利用可能なコードポイント)をサポートします。
有効にするには、[最新のリリース](https://github.com/samhocevar/wincompose/releases/latest)をインストールします。インストールすると、起動時に WinCompose が自動的に実行されます。このモードはアプリがサポートする全てのバージョンの Windows で確実に動作します。
デフォルトでは、このモードは Compose キーとして右 Alt (`KC_RALT`) を使いますが、これは WinCompose 設定と他のキーで [`UNICODE_KEY_WINC`](#input-key-configuration) を定義することで変更できます。
マシンで使うプライマリシステムレイアウトが US ANSI と異なる場合、これらの言語固有のキーコードを使うと、QMK キーマップが実際に画面に出力されるものとより一致するようになります。ただし、これらのキーコードは、内部の対応するデフォルトの US キーコードのエイリアスに過ぎず、キーボードで使われる HID プロトコル自体は本質的に US ANSI に基づいていることに注意してください。
@@ -93,7 +93,7 @@ And to do so, add `reset_keyboard()` to your function or macro, and this will re
## Wiping the EEPROM (Persistent Storage)
If you're having issues with Audio, RGB Underglow, backlighting or keys acting weird, then you can reset the EEPROM (persistent setting storage). Bootmagic is one way to do this, but if that isn't enabled, then you can use a custom macro to do so.
If you're having issues with Audio, RGB Underglow, backlighting or keys acting weird, then you can reset the EEPROM (persistent setting storage). To force an EEPROM reset, use the [`EEP_RST` keycode](quantum_keycodes.md) or [Bootmagic](feature_bootmagic.md) functionality. If neither of those are an option, then you can use a custom macro to do so.
To wipe the EEPROM, run `eeconfig_init()` from your function or macro to reset most of the settings to default.
@@ -19,8 +19,20 @@ The `info.json` file is a JSON formatted dictionary with the following keys avai
* Width of the board in Key Units
*`height`
* Height of the board in Key Units
*`debounce`
* How many milliseconds (ms) to wait for debounce to happen. (Default: 5)
*`diode_direction`
* The direction diodes face. See [`DIRECT_PINS` in the hardware configuration](https://docs.qmk.fm/#/config_options?id=hardware-options) for more details.
*`layout_aliases`
* A dictionary containing layout aliases. The key is the alias and the value is a layout in `layouts` it maps to.
*`layouts`
* Physical Layout representations. See the next section for more detail.
* Physical Layout representations. See the [Layout Format](#layout_format) section for more detail.
*`matrix_pins`
* Configure the pins corresponding to columns and rows, or direct pins. See [Matrix Pins](#matrix_pins) for more detail.
*`rgblight`
* Configure the [RGB Lighting feature](feature_rgblight.md). See the [RGB Lighting](#rgb_lighting) section for more detail.
*`usb`
* Configure USB VID, PID, and other parameters. See [USB](#USB) for more detail.
### Layout Format
@@ -49,25 +61,129 @@ All key positions and rotations are specified in relation to the top-left corner
* The width of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`h`
* The height of the key, in Key Units. Ignored if `ks` is provided. Default: `1`
*`r`
* How many degrees clockwise to rotate the key.
*`rx`
* The absolute position of the point to rotate the key around in the horizontal axis. Default: `x`
*`ry`
* The absolute position of the point to rotate the key around in the vertical axis. Default: `y`
*`ks`
* Key Shape: define a polygon by providing a list of points, in Key Units.
* **Important**: These are relative to the top-left of the key, not absolute.
* Example ISO Enter: `[ [0,0], [1.5,0], [1.5,2], [0.25,2], [0.25,1], [0,1], [0,0] ]`
*`label`
* What to name this position in the matrix.
* This should usually be the same name as what is silkscreened on the PCB at this location.
* This should usually correspond to the keycode for the first layer of the default keymap.
*`matrix`
* A 2 item list describing the row and column location for this key.
## How is the Metadata Exposed?
### Matrix Pins
This metadata is primarily used in two ways:
Currently QMK supports connecting switches either directly to GPIO pins or via a switch matrix. At this time you can not combine these, they are mutually exclusive.
* To allow web-based configurators to dynamically generate UI
* To support the new `make keyboard:keymap:qmk` target, which bundles this metadata up with the firmware to allow QMK Toolbox to be smarter.
#### Switch Matrix
Configurator authors can see the [QMK Compiler](https://docs.api.qmk.fm/using-the-api) docs for more information on using the JSON API.
Most keyboards use a switch matrix to connect keyswitches to the MCU. You can define your pin columns and rows to configure your switch matrix. When defining switch matrices you should also define your `diode_direction`.
Example:
```json
{
"diode_direction":"COL2ROW",
"matrix_pins":{
"cols":["F4","E6","B1","D2"],
"rows":["B0","D3","D5","D4","D6"]
}
}
```
#### Direct Pins
Direct pins are when you connect one side of the switch to GND and the other side to a GPIO pin on your MCU. No diode is required, but there is a 1:1 mapping between switches and pins.
When specifying direct pins you need to arrange them in nested arrays. The outer array consists of rows, while the inner array is a text string corresponding to a pin. You can use `null` to indicate an empty spot in the matrix.
Example:
```json
{
"matrix_pins":{
"direct":[
["A10","A9"],
["A0","B8"],
[null,"B11"],
["B9","A8"],
["A7","B1"],
[null,"B2"]
]
}
}
```
### RGB Lighting
This section controls the legacy WS2812 support in QMK. This should not be confused with the RGB Matrix feature, which can be used to control both WS2812 and ISSI RGB LEDs.
The following items can be set. Not every value is required.
*`led_count`
* The number of LEDs in your strip
*`pin`
* The GPIO pin that your LED strip is connected to
*`animations`
* A dictionary that lists enabled and disabled animations. See [RGB Light Animations](#rgb_light_animations) below.
*`sleep`
* Set to `true` to enable lighting during host sleep
*`split`
* Set to `true` to enable synchronization functionality between split halves
*`split_count`
* For split keyboards, the number of LEDs on each side
*`max_brightness`
* (0-255) What the maxmimum brightness (value) level is
*`hue_steps`
* How many steps of adjustment to have for hue
*`saturation_steps`
* How many steps of adjustment to have for saturation
*`brightness_steps`
* How many steps of adjustment to have for brightness (value)
Example:
```json
{
"rgblight":{
"led_count":4,
"pin":"F6",
"hue_steps":10,
"saturation_steps":17,
"brightness_steps":17,
"animations":{
"all":true
}
}
}
```
#### RGB Light Animations
The following animations can be enabled:
| Key | Description |
|-----|-------------|
| `all` | Enable all additional animation modes. |
@@ -6,12 +6,12 @@ The SPI Master drivers used in QMK have a set of common functions to allow porta
No special setup is required - just connect the `SS`, `SCK`, `MOSI` and `MISO` pins of your SPI devices to the matching pins on the MCU:
|MCU |`SS`|`SCK`|`MOSI`|`MISO`|
|---------------|----|-----|------|------|
|ATmega16/32U2/4|`B0`|`B1` |`B2` |`B3` |
|AT90USB64/128|`B0`|`B1` |`B2` |`B3` |
|ATmega32A |`B4`|`B7` |`B5` |`B6` |
|ATmega328/P |`B2`|`B5` |`B3` |`B4` |
|MCU |`SS`|`SCK`|`MOSI`|`MISO`|
|-----------------|----|-----|------|------|
|ATmega16/32U2/4|`B0`|`B1` |`B2` |`B3` |
|AT90USB64/128/162|`B0`|`B1` |`B2` |`B3` |
|ATmega32A |`B4`|`B7` |`B5` |`B6` |
|ATmega328/P |`B2`|`B5` |`B3` |`B4` |
You may use more than one slave select pin, not just the `SS` pin. This is useful when you have multiple devices connected and need to communicate with them individually.
`SPI_SS_PIN` can be passed to `spi_start()` to refer to `SS`.
@@ -87,7 +87,7 @@ To enable this setting, add this to your `config.h`:
#define IGNORE_MOD_TAP_INTERRUPT
```
Similar to Permissive Hold, this alters how the firmware processes inputs for fast typists. If you press a Mod Tap key, press another key, release the Mod Tap key, and then release the normal key, it would normally output the tapping function for both keys. This may not be desirable for rolling combo keys.
Similar to Permissive Hold, this alters how the firmware processes inputs for fast typists. If you press a Mod Tap key, press another key, release the Mod Tap key, and then release the normal key, it would normally output the Mod plus the normal key, even if pressed within the `TAPPING_TERM`. This may not be desirable for rolling combo keys, or for fast typists who have a Mod Tap on a frequently used key (`RCTL_T(KC_QUOT)`, for example).
Setting `Ignore Mod Tap Interrupt` requires holding both keys for the `TAPPING_TERM` to trigger the hold function (the mod).
@@ -98,7 +98,7 @@ For Instance:
-`SFT_T(KC_A)` Up
-`KC_X` Up
Normally, this would send `X` (`SHIFT`+`x`). With `Ignore Mod Tap Interrupt` enabled, holding both keys are required for the `TAPPING_TERM` to register the hold action. A quick tap will output `ax` in this case, while a hold on both will still output `X` (`SHIFT`+`x`).
Normally, this would send a capital `X` (`SHIFT`+`x`), or, Mod + key. With `Ignore Mod Tap Interrupt` enabled, holding both keys are required for the `TAPPING_TERM` to register the hold action. A quick tap will output `ax` in this case, while a hold on both will still output capital `X` (`SHIFT`+`x`).
?> __Note__: This only concerns modifiers and not layer switching keys.
The UART drivers used in QMK have a set of common functions to allow portability between MCUs.
Currently, this driver does not support enabling hardware flow control (the `RTS` and `CTS` pins) if available, but may do so in future.
## AVR Configuration
No special setup is required - just connect the `RX` and `TX` pins of your UART device to the opposite pins on the MCU:
|MCU |`TX`|`RX`|`CTS`|`RTS`|
|-------------|----|----|-----|-----|
|ATmega16/32U2|`D3`|`D2`|`D7` |`D6` |
|ATmega16/32U4|`D3`|`D2`|`D5` |`B7` |
|AT90USB64/128|`D3`|`D2`|*n/a*|*n/a*|
|ATmega32A |`D1`|`D0`|*n/a*|*n/a*|
|ATmega328/P |`D1`|`D0`|*n/a*|*n/a*|
## ChibiOS/ARM Configuration
You'll need to determine which pins can be used for UART -- as an example, STM32 parts generally have multiple UART peripherals, labeled USART1, USART2, USART3 etc.
To enable UART, modify your board's `halconf.h` to enable the serial driver:
```c
#define HAL_USE_SERIAL TRUE
```
Then, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
```c
#undef STM32_SERIAL_USE_USART2
#define STM32_SERIAL_USE_USART2 TRUE
```
Configuration-wise, you'll need to set up the peripheral as per your MCU's datasheet -- the defaults match the pins for a Proton-C, i.e. STM32F303.
|`#define SERIAL_DRIVER` |USART peripheral to use - USART1 -> `SD1`, USART2 -> `SD2` etc.|`SD1` |
|`#define SD1_TX_PIN` |The pin to use for TX |`A9` |
|`#define SD1_TX_PAL_MODE` |The alternate function mode for TX |`7` |
|`#define SD1_RX_PIN` |The pin to use for RX |`A10` |
|`#define SD1_RX_PAL_MODE` |The alternate function mode for RX |`7` |
|`#define SD1_CTS_PIN` |The pin to use for CTS |`A11` |
|`#define SD1_CTS_PAL_MODE`|The alternate function mode for CTS |`7` |
|`#define SD1_RTS_PIN` |The pin to use for RTS |`A12` |
|`#define SD1_RTS_PAL_MODE`|The alternate function mode for RTS |`7` |
## Functions
### `void uart_init(uint32_t baud)`
Initialize the UART driver. This function must be called only once, before any of the below functions can be called.
#### Arguments
-`uint32_t baud`
The baud rate to transmit and receive at. This may depend on the device you are communicating with. Common values are 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200.
---
### `void uart_putchar(uint8_t c)`
Transmit a single byte.
#### Arguments
-`uint8_t c`
The byte (character) to send, from 0 to 255.
---
### `uint8_t uart_getchar(void)`
Receive a single byte.
#### Return Value
The byte read from the receive buffer.
---
### `bool uart_available(void)`
Return whether the receive buffer contains data. Call this function to determine if `uart_getchar()` will return meaningful data.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.