* fix link in docs/ja/feature_split_keyboard.md
* fix link in docs/ja/faq_build.md
* fix link in docs/ja/faq_general.md
* fix link in docs/ja/faq_keymap.md
* fix link in docs/ja/how_a_matrix_works.md
* fix link in docs/ja/reference_glossary.md
* [Driver] bugfix reset the scaling register flag to FALSE
* Update drivers/issi/is31fl3741.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add CS & SW defines for ISSI3741
* Make IS31FL3741 control register update clearer
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Jumail Mundekkat <mundekkat@hotmail.com>
* Adding VIA support for sixkeyboard
* Update keyboards/sixkeyboard/keymaps/via/keymap.c
* Update keyboards/sixkeyboard/keymaps/via/keymap.c
* Update keyboards/sixkeyboard/keymaps/via/keymap.c
* Update keyboards/sixkeyboard/keymaps/via/keymap.c
* Update keymap.c
added suggested header. left my name out and changed year to 2020.
* split up the e85 into hotswap and soldered variants
* remove layout_all LAYOUT macro for hotswap pcb
* add copyright header to to all config files
* remove list of alternate bootloaders
* spruce up config file
* comply with PR check list
* Update keyboards/exclusive/e85/hotswap/info.json
* Update keyboards/exclusive/e85/hotswap/info.json
* Update keyboards/exclusive/e85/hotswap/info.json
* Update keyboards/exclusive/e85/rules.mk
* Update keyboards/exclusive/e85/config.h
* Update keyboards/exclusive/e85/hotswap/config.h
* Update keyboards/exclusive/e85/soldered/config.h
* remove LAYOUT_all in hotswap and also remove superfluous comments
* remove the soldered tsangan map
* replaced #define PRODUCT_ID 0x1157 with #define PRODUCT_ID 0x2157
replaced product id to distinguish rev2 from rev1.
bakingpy gave me permission through discord chat.
* add ref_functions.md translation
* modify internal link for ja
* update based on comment
* reflect #9892 change
* update based on comment
* update based on comment
The recent change to unnest macros put the enter on the wrong matrix key. On the 1uprgb, the ANSI and ISO enters share the same cell as does the ANSI and ISO backslash.
* Fixed Spanish keymap extra ES_DIAE symbol
`ES_DIAE` should be `S(ES_ACUT)` not `S(ES_GRV)`
* Update quantum/keymap_extras/keymap_spanish.h
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* K-Type refactor
* Declare QMK in product name again
* Hopefully fix matrix scanning
* Maybe this time
* Partial (literally) RGB Matrix support
* Put RGB_MATRIX_ENABLE into rgb keymap for now
* Add ifdefs for RGB config
* Set layer 1 to actually be layer 1...
* Update keyboards/k_type/readme.md
* Put all RGB config in keymap for now
* Set SDB high?
* Before `rgb_matrix_init()` would be best
* User level, not keyboard
* Combating dropped keys
* Nope
* Readme for RGB keymap
* Remove custom matrix
Some STM32 chips have STM32_DMA1_STREAM1 as the first DMA stream, others
(F4xx, F7xx, H7xx) have STM32_DMA1_STREAM0. Instead of those names, use
STM32_DMA_STREAM(0), which should always give the first stm32_dma_stream_t
structure in the DMA streams array, so that the stream ID would be
calculated correctly.
* Better handle LTO_ENABLE
Especially when calling from command line
* Replace LINK_TIME_OPTIMIZATION_ENABLE with LTO_ENABLE
* Remove long for LTO from show_options.mk
* Update vusb to match 3rd endpoint.
- With the addition of https://github.com/qmk/v-usb/pull/1 a 3rd endpoint (endpoint4) becomes available.
- We can assign mouse/extrakeys to that endpoint as its a desirable feature and leave rawhid and console to compete for the 2nd endpoint.
NOTE: The version of vusb.c in future branch is older than master. Just remember that it will need a #error if both raw_hid and console are enabled at the same time.
* Final Fixes
* Update tmk_core/protocol/vusb/vusb.c
* Update tmk_core/protocol/vusb/vusb.c
* Update tmk_core/protocol/vusb/usbconfig.h
* Update tmk_core/protocol/vusb/usbconfig.h
* Update tmk_core/protocol/vusb/usbconfig.h
* Update tmk_core/protocol/vusb/usbconfig.h
* Updated vusb submodule to latest commit
* Add `st-flash` flash target
Add support for flashing the firmware via the `st-flash` utility from
the STLink Tools package (https://github.com/stlink-org/stlink).
* Add `st-flash` to the `qmk flash -b` output
* Add support for hsv->rgb conversion without using CIE curve.
* Modify anavi/macropad8 to disable unicode (was unused), otherwise firmware size is too large.
* Consolidate TKC projects and increase VIA keymap count to 4.
* Updated readme files.
* Removed config.h via limitation of 2 dynamic keymaps
* Reduce dynamic keymaps from 4 to 3 due to EEPROM space limitations.
* Update dynamic_keymap.c
* Restore 4 dynamic keymaps for VIA in TKC projects.
* Update quantum/dynamic_keymap.c
* Initialize Layer State on startup
Right now, on startup, the default layer state gets called and set, triggering the callback functions for the default layer state. However, the normal layer state never actually gets initialized. It's set to 0 directly, by default, but the callback functions are never actually called. This creates some inconsistency in the behavior for end users. This adds a simple "clear" that triggers the callback on startup. This should produce more consisten behavior between the two functions and layer masks.
* Stupid hack
* Fix type casting?
* Fix compile issues with magic is disabled
* Tweak the Christmas animation effect to be less harsh on the eyes
* Further improve the tweaked Christmas animation code
- Use constants where it makes sense
- Instead of complicated math, use a static variable to keep track if it's animating from or to red
- Don't use pow (but a simple macro instead)
- Using floating point math is necessary for the fraction in the cubic bezier function to work
* Update docs for the tweaked Christmas animation effect
* Further improve memory usage
- Don't use floats, but 32 bit ints instead (where needed)
- Replace limits.h with constant
* Fix typo
* add support for hid gamepad interface
add documentation for HID joystick
Add joystick_task to read analog axes values even when no key is pressed or release. update doc
Update docs/feature_joystick.md
Manage pin setup and read to maintain matrix scan after analog read
* Incorporates patches and changes to HID reporting
There are some patches provided by @a-chol incorporated on this commit,
and also some changes I made to the HID Report structure.
The most interesting is the one dealing with number of buttons: Linux
doesn't seem to care, but Windows requires the HID structure to be byte
aligned (that's in the spec). So if one declares 8/16/32... buttons they
should not have any issues, but this is what happens when you have 9
buttons:
```
bits |0|1|2|3|4|5|6|7|
|*|*|*|*|*|*|*|*| axis 0 (report size 8)
|*|*|*|*|*|*|*|*| ...
|*|*|*|*|*|*|*|*|
|*|*|*|*|*|*|*|*|
|*|*|*|*|*|*|*|*|
|*|*|*|*|*|*|*|*|
|*|*|*|*|*|*|*|*| axis 6
|*|*|*|*|*|*|*|*| first 8 buttons (report size 1)
|*| | | | | | | | last of 9 buttons, not aligned
```
So for that I added a conditonal that will add a number of reports with
size 1 to make sure it aligns to the next multiple of 8. Those reports
send dummy inputs that don't do anything aside from aligning the data.
Tested on Linux, Windows 10 and Street Fighter (where the joystick is
recognized as direct-input)
* Add save and restore of each pin used in reading joystick (AVR).
Allow output pin to be JS_VIRTUAL_AXIS if the axis is connected to Vcc
instead of an output pin from the MCU.
Fix joystick report id
Fix broken v-usb hid joystick interface. Make it more resilient to unusual settings (none multiple of eight button count, 0 buttons or 0 axes)
Correct adc reading for multiple axes. Piecewise range conversion for uncentered raw value range. Input, output and ground pin configuration per axis.
Documentation fixes
* Fix port addressing for joystick analog read
* The other required set of changes
As per the PR, the changes still holding it up.
Add onekey for testing.
Fix ARM builds.
Fix device descriptor when either axes or buttons is zero.
Add compile-time check for at least one axis or button.
Move definition to try to fix conflict.
PR review comments.
qmk cformat
* avoid float functions to compute range mapping for axis adc reading
* Remove V-USB support for now. Updated docs accordingly.
* Update tmk_core/protocol/lufa/lufa.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/usb_descriptor.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/usb_descriptor.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/usb_descriptor.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Add support for joystick adc reading for stm32 MCUs. Fix joystick hid report sending for chibios
* Fix HID joystick report sending for ChibiOS.
Add one analog axis to the onekey:joystick keymap.
Fix pin state save and restore during joystick analog read for STM32
MCUs.
* Update tmk_core/protocol/chibios/usb_main.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/lufa/lufa.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Add missing mcuconf.h and halconf.h to onekey:joystick keymap.
Add suggested fixes from PR.
* Switch saveState and restoreState signature to use pin_t type.
onekey:joystick : add a second axis, virtual and programmatically animated.
* Update docs/feature_joystick.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update docs/feature_joystick.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Add PR corrections
* Remove halconf.h and mcuconf.h from onekey keymaps
* Change ADC_PIN to A0
Co-authored-by: achol <allecooll@hotmail.com>
Co-authored-by: José Júnior <jose.junior@gmail.com>
Co-authored-by: a-chol <achol@notamail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update Space Cadet to use Custom Tapping Term functionality
* Detect correct keycode for space cadet tapping term
* Update tap dancing to use global custom tapping term
* Update documentation for Tap Dances
* formatting pass
* Apply suggestions from code review
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/feature_tap_dance.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update for future
* Update user keymaps for space cadet
* Fix typos
* Clean up tapping term stuff
* Fix compiler issue if NO_ACTION_TAPPING is enabled
Co-authored-by: fauxpark <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Disable NKRO on V-USB controllers
* not _currently_ supported text
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Re-fix the dual-bank bootloader stuff.
* Use wait_ms() instead of using nop's for a delay, as ChibiOS is actually running at the time of bootloader jump.
Mousekey scrolling should have a separate repeat variable
to keep track of scrolling acceleration, instead of being
tied to mouse movement scolling in mousekeys. The send function
should record when the last movement was made since this is
when movement is actually sent. Doing this fixes the bug where
the initial press of a mousekey scroll button causes a double scroll.
Signed-off-by: Daniel Hong <daniel.hong@live.com>
* Initial work for consolidation of board files and default ChibiOS configs.
* Migrate F401/F411 black pills for testing.
* Add early init bootloader jump flag.
* Add support for I2C in order to use i2c_scanner keymap.
* Add F401/F411 HSE bypass to get things booting.
* Exempt "hooked" ChibiOS conf files from updater script.
* Fix up ordering for bootloader_defs file check.
* Match previous $(KEYBOARD_PATHS) value for Proton-C, updated for all board configs.
* Add a compiling layout based on minidox
* Add the correct pins
* Add old for science code
* Update to 2020 standards
* Get the keymap working
* update config
* Update pinout
* Fix pins
* Make requested changes
* Add info.json for configurator
* for science - PR comments
* Apply suggestions from code review
* setup handwired pteron38
* Clean up readme
* readme follow template
* c formatting conventions
* remove file size comments from rules.mk
* use direct link to imgur image
* Apply suggestions from code review
* add license
* kbd67/mkiirgb - allow disabling rgb matrix
wrap rgb matrix funs in defines
* kbd67mkiirgb - changes per review
remove kb funcs that just call the user version. what's left is all rgb
matrix stuff so we can just wrap the whole file.
* Initial prep for PR
* Fixing jsons for revs
* Remove old keymap ref in readme
* Add Rev1 default layout
* Fix extra comma in default r1 keymap
* Changed default keymap for r1 to match new split bottom row macro name, updated via keymap readme, updated r1 json to match layout macro name, updated split space macro for r1
* Moved combo configs to default keymaps, removed unused bootloader selections
* Update keyboards/underscore33/rev1/rules.mk
* Update keyboards/underscore33/rev2/rules.mk
* Refactor _33 folder structure
* Add VIA keymap to rev1
* Rename macros and product_id as suggested
Specifically, when rgb matrix is enabled and using the ws2812 driver, and rgb light is enabled at the same time, print a message about coexistance because it can cause issues, since you cannot change pins/config for the WS2812 driver.
* add support for ModelM USB board
* EMI improvement: remove unnecessary toggling of MOSI pin
* address review comments
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/mschwingen/modelm/config.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/mschwingen/modelm/config.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/mschwingen/modelm/keymaps/default/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* update printf usage
* add comment
* EMI improvement: remove unnecessary toggling of MOSI signal
* remove trailing space
* use shorter macros as suggested in review by noroadsleft, re-format table to line up columns
* Update keyboards/mschwingen/modelm/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mschwingen/modelm/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mschwingen/modelm/README.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mschwingen/modelm/README.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
use spi_read from core insteads of our own copy
Co-authored-by: Ryan <fauxpark@gmail.com>
* include spi_master.c to use spi_read()
* Update keyboards/mschwingen/modelm/README.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Apply suggestions from code review: correct indenting in keymap
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Apply suggestions from code review
use automatic variant defines from makefile instead of defining our own
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/mschwingen/modelm/rules.mk: use QUANTUM_LIB_SRC for uart.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Michael Schwingen <michael@schwingen.org>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* added matrix 8xv2.0 additional keyboard
* Apply suggestions from code review
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* add copyright and speed up the matrix scanning
* Update keyboards/matrix/m20add/rules.mk
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* added nemui layout
* via support working
* added license headers for c and h files
* Update keyboards/nemui/keymaps/via/rules.mk
* Update keyboards/nemui/nemui.c
* Update keyboards/nemui/config.h
* Update keyboards/nemui/readme.md
* Update keyboards/nemui/rules.mk
* removed nemui.json as it was supposed to only be in via repo
* Update keyboards/nemui/keymaps/default/keymap.c
* Update keyboards/nemui/info.json
* Update keyboards/nemui/info.json
* Update keyboards/nemui/keymaps/via/keymap.c
* Update keyboards/nemui/keymaps/via/keymap.c
* first iteration of my keymap
* * move to userspace
* "script" modes
* keymap bling
* OM and RUPA keys
and tryin to micro-optimize in process_records.c
* woops
swap shifted rupas
forgot to add codepoint for OM
* Apply suggestions from code review
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add call to process_record_keymap, per review
* fall through to process_record_keymap
* license headers
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add in drewguy's code with a few additions to the keymap
* add VID and PID
* fixup defualt keymap
* add VIA keymap
* thanks to bigchimpo for reminding me to put an Fn key in the default keymap
* make sure we have the right gitugithub url for drew
* remove description as per PR checklist
* append readme with more information
* Update keyboards/holyswitch/southpaw75/config.h
* Update keyboards/holyswitch/southpaw75/info.json
* Update keyboards/holyswitch/southpaw75/southpaw75.h
* Update keyboards/holyswitch/southpaw75/info.json
* [kbdfans] Added dbroqua layout for kbd6x
Add dbroqua keymap for kbd6x
Add dbroqua layout for kbd6x with HHKB style and RGB.
* Update keymap.c
* Change based on zvecr
* Added RESET button
* Add support for keyboard 'Bolt'
Add support for keyboard 'Bolt'
* Update info.json
* Update info.json
* Update keyboards/lazydesigners/bolt/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/lazydesigners/bolt/rules.mk
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/lazydesigners/bolt/readme.md
Co-authored-by: Joel Challis <git@zvecr.com>
* Update info.json
* Update keyboards/lazydesigners/bolt/info.json
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lazydesigners/bolt/bolt.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/lazydesigners/bolt/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/lazydesigners/bolt/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/lazydesigners/bolt/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/lazydesigners/bolt/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/lazydesigners/bolt/keymaps/default/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* via keymap for boardsource/3x4
* fix formatting
* Apply suggestions from code review
fix rules.mk
* Update keyboards/boardsource/3x4/rules.mk
* use unique product ID
* update vendor id to be unique, update product id to make more sense
* First commit
* Added ChibiOS files
* renamed files to remove capital letters
* Fixed layout references
* fixed image reference
* Fixing errors
* Fixed config.h
* changed second up to fn key
* renamed files and added beginning of via compatibility
* renamed keyboard
* removed vscode files
* fixing files for via compatibility
* adding via files
* working via compatibility
* Update readme.md
* Update readme.md
* First commit
* Added ChibiOS files
* renamed files to remove capital letters
* Fixed layout references
* fixed image reference
* Fixing errors
* Fixed config.h
* changed second up to fn key
* renamed files and added beginning of via compatibility
* renamed keyboard
* removed vscode files
* fixing files for via compatibility
* adding via files
* working via compatibility
* added license header to via file
* preparing for pull request
* Fixed firmware according to pull request feedback
* fixed readme according to pull request feedback
* Updated readme and removed unnecessary layers in default/keymap.c
* removed whitespace
* updated keymap readme to match suggestion
* Initial commit for HHKB Lite 2
* Rearrange keymap
* Clean up config
* Fix pin assignments
* Code and filename cleanup
* Add README
* Apply suggestions from code review
Code cleanup
* Update keyboards/hhkb_lite_2/README.md
Documentation cleanup
* Change Vendor ID to unused
* One more LAYOUT
* Via keymap for HHKB Lite 2
* Remove redundant keymap.c
* Add README for Via keymap
* Fix vendorId for Via keymap
* Apply suggestions from code review
Cleanup based on review feedback
* Clean up via keymap makefile rules
* Switch to C keymap instead of JSON for Via layout
* Move bootmagic key config to main
Moved to main keyboard config to be shared by all keymaps.
* Address PR feedback
* Reformat config comments
* Format rules.mk comments
* Rename README -> readme
* Use `make` instead of `qmk` in examples
* Issue 9942: Add Quantum defines
Add codes to quantum_keycodes for LSA, RSA, RCS, and their corresponding _T macros
* 9942: Add documentation for new defines
Add documentation for new defines in feature request 9942. Also define SAGR and SAGR_T as aliases for RSA and RSA_T.
* Update quantum/quantum_keycodes.h
* Update docs/keycodes.md
* Update docs/keycodes.md
* Update docs/keycodes.md
* Update docs/keycodes.md
* Updating keymaps for Gingham and DMQ Design SPIN and adding keymap for BoardSource 4x12
* Update keyboards/boardsource/4x12/keymaps/codecoffeecode/keymap.c
* cleaning up
* got some working bones
* working pretty well
* really livin' now
* all done
* copyright adjustments
* default keymap
* readme
* no descrip
* remove trailing slashes
* remove blank line
* remove trailing slashes
* clean up readme
* clean up rules spacing
* bootloader spacing
* made quick json from KLE converter
* remove postageboard mini references
* add actual manu and product values
* add make example
* rework
* remove double bootload define
* smoller image
* liscensed
* correct dimensions
* dimensions
Specifically, don't want to have both RGBLight and RGB Matrix (with WS2812) enabled at the same time. This will cause issues in usage, but apparently not when compiling. Additionally, the led matrix was not encapsulated with preprocessor code.
* ext65rev2 initial
* open drain change and config
* pwm
* pwm streams
* spi
* ws2812 spi
* oled
* enable sleep
* keymap and dissable oled
* readd oleds
* nooled
* led_update_kb revised
* update and remove board specific files and add to ext65rev2.c
* Update OLED usb status
* Update keyboards led state
* Layer state set kb
* Return state
* Update keyboards led state
* Update OLED usb status
* merge master and merge rev folders
* add readme
* move board_init to only if OLED is enabled
* update readme
* update rules.mk
* Remove OLED from rules.mk
* Update config.h
* show AEBoards
* Update keyboards/aeboards/ext65/rev2/rules.mk
Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
## Changes Requiring User Action :id=changes-requiring-user-action
### Relocated Keyboards :id-relocated-keyboards
#### The Key Company project consolidation ([#9547](https://github.com/qmk/qmk_firmware/pull/9547))
#### relocating boards by flehrad to flehrad/ folder ([#9635](https://github.com/qmk/qmk_firmware/pull/9635))
Keyboards released by The Key Company and keyboards designed by flehrad have moved to vendor folders. If you own any of the keyboards listed below, please use the new names to compile your firmware moving forward.
This pull request changes the configuration for Keebio split boards to use the same RGB strip wiring for each half, which provides the following improvements:
* Easier wiring due to one fewer wire needed (the wire between left DOut to extra data pin) and the fact that wiring is the same for both halves.
* RGB LEDs can be controlled by each half now instead of just master half.
* Extra data line is freed up to allow for I2C usage instead of serial.
If you have customized the value of `RGBLED_SPLIT` for your keymap, you will need to undefine it using `#undef RGBLED_SPLIT` before defining it to your customized value.
This change affects:
* BFO-9000
* Fourier
* Iris rev2
* Levinson, revs. 1 and 2
* Nyquist, revs. 1 and 2
* Quefrency rev1
* Viterbi, revs. 1 and 2
### Changes to Core Functionality :id=core-updates
* Bigger Combo index ([#9318](https://github.com/qmk/qmk_firmware/pull/9318))
Allows the Combo feature to support more than 256 combos.
Any fork that uses `process_combo_event` needs to update the function's first argument to `uint16_t`:
* Old function: `void process_combo_event(uint8_t combo_index, bool pressed)`
* New function: `void process_combo_event(uint16_t combo_index, bool pressed)`
## Core Changes :id=core-changes
### Fixes :id=core-fixes
* Mousekeys: scrolling acceleration is no longer coupled to mouse movement acceleration ([#9174](https://github.com/qmk/qmk_firmware/pull/9174))
* Keymap Extras: correctly assign Question Mark in Czech layout ([#9987](https://github.com/qmk/qmk_firmware/pull/9987))
### Additions and Enhancements :id=core-additions
* allow for WS2812 PWM to work on DMAMUX-capable devices ([#9471](https://github.com/qmk/qmk_firmware/pull/9471))
* Newer STM32 MCUs have a DMAMUX peripheral, which allows mapping of DMAs to different DMA streams, rather than hard-defining the target streams in silicon.
* Affects STM32L4+ devices, as well as the soon-to-be-supported-by-QMK STM32G4/H7 families.
* Tested on F303/Proton C (ChibiOS v19, non-DMAMUX), G474 (ChibiOS v20, with DMAMUX).
* dual-bank STM32 bootloader support ([#8778](https://github.com/qmk/qmk_firmware/pull/8778) and [#9738](https://github.com/qmk/qmk_firmware/pull/9738))
* Adds support for STM32 dual-bank flash bootloaders, by toggling a GPIO during early init in order to charge an RC circuit attached to `BOOT0`.
* The main rationale behind this is that dual-bank STM32 devices unconditionally execute user-mode code, regardless of whether or not the user-mode code jumps to the bootloader. If either flash bank is valid (and `BOOT0` is low), then the built-in bootloader will skip any sort of DFU.
* This PR allows for the initialisation sequencing to charge the RC circuit based on the example circuit posted on Discord, effectively pulling `BOOT0` high before issuing the system reset. As the RC circuit takes a while to discharge, the system reset executes the ROM bootloader which subsequently sees `BOOT0` high, and starts executing the DFU routines.
* Tested with STM32L082 (with current QMK+current ChibiOS), and STM32G474 (against ChibiOS 20.x).
* update Space Cadet and Tap Dance features to use Custom Tapping Term when appropriate ([#6259](https://github.com/qmk/qmk_firmware/pull/6259))
* For the Tap Dance feature, this completely removes the need for the `ACTION_TAP_DANCE_FN_ADVANCED_TIME` dance.
* This implements a joystick feature, including a joystick_task function called from TMK, specific keycodes for joystick buttons and a USB HID interface.
* Tested on V-USB backend and Proton C; compiles but untested on LUFA.
* In order to test, you have to add `JOYSTICK_ENABLE = yes` to your `rules.mk` and
```c
#define JOYSTICK_BUTTON_COUNT 8
#define JOYSTICK_AXES_COUNT 2
```
in your config.h.
* Christmas RGB Underglow animation now fades between green and red ([#7648](https://github.com/qmk/qmk_firmware/pull/7648))
* `RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL` has been greatly decreased; please check your animation if you have customized this value.
* layer state now initializes on startup ([#8318](https://github.com/qmk/qmk_firmware/pull/8318))
* This should produce more consistent behavior between the two functions and layer masks.
* added support for HSV->RGB conversion without using CIE curve ([#9856](https://github.com/qmk/qmk_firmware/pull/9856))
* added NOEEPROM functions for RGB Matrix ([#9487](https://github.com/qmk/qmk_firmware/pull/9487))
* Added eeprom_helpers for toggle, mode, sethsv, speed, similar to rgblight versions.
* Added set_speed function.
* Added helper functions, similar to those in rgblight, in order to add NOEEPROM versions of toggle, step, hue, sat, val, and speed.
* Minor: spelling correction for EEPROM in a debug message.
* flashing firmware using `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink) is now supported ([#9964](https://github.com/qmk/qmk_firmware/pull/9964))
* add ability to dump all makefile variables for the specified target ([#8256](https://github.com/qmk/qmk_firmware/pull/8256))
* Adds a new subtarget to builds, `dump_vars`, which allows for printing out all the variables that make knows about, after all substitutions occur.
* work begun for consolidation of ChibiOS platform files ([#8327](https://github.com/qmk/qmk_firmware/pull/8327) and [#9315](https://github.com/qmk/qmk_firmware/pull/9315))
* Start of the consolidation work to move the ChibiOS board definitions as well as the default set of configuration files for existing board definitions used by keyboards.
* Uses `/platforms/chibios` as previously discussed on discord.
* Consolidates the Proton C configs into the generic F303 definitions.
* Allows for defining a default set of `chconf.h`, `halconf.h`, and `mcuconf.h` files within the platform definition, which is able to be overridden by the keyboard directly, though include path ordering.
* Adds template `chconf.h`, `halconf.h`, `mcuconf.h`, and `board.h` that can be dropped into a keyboard directory, in order to override rather than replace the entire contents of the respective files.
* Removed Proton C QMK board definitions, falling back to ChibiOS board definitions with QMK overrides.
* Various tidy-ups for USB descriptor code ([#9005](https://github.com/qmk/qmk_firmware/pull/9005))
* Renamed `keyboard_led_stats` in lufa.c and ChibiOS usb_main.c to `keyboard_led_state`, as well as `vusb_keyboard_leds`, for consistency
* Formatted CDC and MIDI descriptors better
* Removed `ENDPOINT_CONFIG` macro, it seems pointless and removes the need for endpoint address defines in the middle of the endpoint numbering enum
* Fixed (possibly?) V-USB `GET_REPORT` request handling. Not sure about this one, but the existing code appears to always return an empty report - now `send_keyboard` sets this variable to the current report, matching what the LUFA code does.
* converted `CONSUMER2BLUEFRUIT()` and `CONSUMER2RN42()` macros to static inline functions ([#9055](https://github.com/qmk/qmk_firmware/pull/9055))
* Additional cleanups for V-USB code ([#9310](https://github.com/qmk/qmk_firmware/pull/9310))
* Removing the UART stuff entirely, now that we have Console support. Also fixing up various other things; switching some `debug()` calls to `dprintf()`, moved `raw_hid_report` out of the way so that we can implement the shared endpoint stuff.
* removed inclusion of `adafruit_ble.h` from `ssd1306.c` ([#9355](https://github.com/qmk/qmk_firmware/pull/9355))
* `outputselect.c` is no longer compiled if Bluetooth is disabled ([#9356](https://github.com/qmk/qmk_firmware/pull/9356))
* `analogRead()` deprecated in favor of `analogReadPin()` ([#9023](https://github.com/qmk/qmk_firmware/pull/9023))
* forcibly disable NKRO on V-USB controllers ([#9054](https://github.com/qmk/qmk_firmware/pull/9054))
* removed warning if running backlight on STM32F072 ([#10040](https://github.com/qmk/qmk_firmware/pull/10040))
@ -45,9 +45,9 @@ Then place this include at the top of your code:
Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC.
Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-based, whereas the F3 has 4 ADCs and the channels are 1 based. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
|ADC|Channel|STM32F0XX|STM32F3XX|
|ADC|Channel|STM32F0xx|STM32F3xx|
|---|-------|---------|---------|
|1 |0 |`A0` | |
|1 |1 |`A1` |`A0` |
@ -122,32 +122,29 @@ Also note that the F0 and F3 use different numbering schemes. The F0 has a singl
|`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
|`analogRead(pin)` |Reads the value from the specified Arduino pin, eg. `4` for ADC6 on the ATmega32U4. |
|`analogReadPin(pin)`|Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4. |
|`pinToMux(pin)` |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `F6` for ADC6 on the ATmega32U4. |
|`pinToMux(pin)` |Translates a given pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. |
### ARM
Note that care was taken to match all of the functions used for AVR devices, however complications in the ARM platform prevent that from always being possible. For example, the `STM32` chips do not have assigned Arduino pins. We could use the default pin numbers, but those numbers change based on the package type of the device. For this reason, please specify your target pins with their identifiers (`A0`, `F3`, etc.). Also note that there are some variants of functions that accept the target ADC for the pin. Some pins can be used for multiple ADCs, and this specified can help you pick which ADC will be used to interact with that pin.
|`analogReadPin(pin)`|Reads the value from the specified QMK pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
|`analogReadPinAdc(pin, adc)`|Reads the value from the specified QMK pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function.|
|`pinToMux(pin)` |Translates a given QMK pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)".|
|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and adc combination. See your MCU's datasheet for more information.|
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
|`analogReadPinAdc(pin, adc)`|Reads the value from the specified pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function. |
|`pinToMux(pin)` |Translates a given pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|`adc_read(mux)`|Reads the value from the ADC according to the specified pin and ADC combination. See your MCU's datasheet for more information. |
## Configuration
## ARM
The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates.
The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.
|ADC_CIRCULAR_BUFFER|`bool`|`false` |If `TRUE`, then the implementation will use a circular buffer.|
|ADC_NUM_CHANNELS |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.|
|ADC_BUFFER_DEPTH |`int` |`2` |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to `2` bytes so we can contain our one value. This could be set to 1 if you opt for a 8-bit or lower result.|
|ADC_SAMPLING_RATE |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
|ADC_RESOLUTION |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
|`ADC_CIRCULAR_BUFFER`|`bool`|`false` |If `true`, then the implementation will use a circular buffer.|
|`ADC_NUM_CHANNELS` |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.|
|`ADC_BUFFER_DEPTH` |`int` |`2` |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to 2 bytes so we can contain our one value. This could be set to 1 if you opt for an 8-bit or lower result.|
|`ADC_SAMPLING_RATE` |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. |
|`ADC_RESOLUTION` |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. |
@ -324,11 +324,9 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
```
* `LAYOUTS`
* A list of [layouts](feature_layouts.md) this keyboard supports.
* `LINK_TIME_OPTIMIZATION_ENABLE`
* `LTO_ENABLE`
* Enables Link Time Optimization (LTO) when compiling the keyboard. This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable).
However, this will automatically disable the legacy TMK Macros and Functions features, as these break when LTO is enabled. It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`. (Note: This does not affect QMK [Macros](feature_macros.md) and [Layers](feature_layers.md).)
* `LTO_ENABLE`
* Has the same meaning as `LINK_TIME_OPTIMIZATION_ENABLE`. You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`.
## AVR MCU Options
* `MCU = atmega32u4`
@ -373,10 +371,8 @@ Use these to enable or disable building certain features. The more you have enab
* MIDI controls
* `UNICODE_ENABLE`
* Unicode
* `BLUETOOTH_ENABLE`
* Legacy option to Enable Bluetooth with the Adafruit EZ-Key HID. See BLUETOOTH
* `BLUETOOTH`
* Current options are AdafruitEzKey, AdafruitBLE, RN42
* Current options are AdafruitBLE, RN42
* `SPLIT_KEYBOARD`
* Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
@ -160,8 +160,6 @@ See the ST datasheet for your particular MCU to determine these values. Unless y
Currently only hardware PWM is supported, not timer assisted, and does not provide automatic configuration.
?> Backlight support for STM32F072 has had limited testing, so YMMV. If unsure, set `BACKLIGHT_ENABLE = no` in your `rules.mk`.
### Software PWM Driver :id=software-pwm-driver
In this mode, PWM is "emulated" while running other keyboard tasks. It offers maximum hardware compatibility without extra platform configuration. The tradeoff is the backlight might jitter when the keyboard is busy. To enable, add this to your `rules.mk`:
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules and the Bluefruit EZ-Key, the latter of which is not produced anymore. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
|Board |Bluetooth Protocol |Connection Type |rules.mk |Bluetooth Chip|
|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy | SPI |`BLUETOOTH = AdafruitBLE` | nRF51822 |
@ -24,16 +23,12 @@ Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit
A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip.
## Adafruit EZ-Key hid
This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.
<!-- FIXME: Document bluetooth support more completely. -->
@ -22,7 +22,7 @@ To finish the recording, press the `DYN_REC_STOP` layer button. You can also pre
To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
It is possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again. You can disable this completly by defining `DYNAMIC_MACRO_NO_NESTING` in your `config.h` file.
It is possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again. You can disable this completely by defining `DYNAMIC_MACRO_NO_NESTING` in your `config.h` file.
?> For the details about the internals of the dynamic macros, please read the comments in the `process_dynamic_macro.h` and `process_dynamic_macro.c` files.
The keyboard can be made to be recognized as a joystick HID device by the operating system.
This is enabled by adding `JOYSTICK_ENABLE` to `rules.mk`. You can set this value to `analog`, `digital`, or `no`.
!> Joystick support is not currently available on V-USB devices.
The joystick feature provides two services:
* reading analog input devices (eg. potentiometers)
* sending gamepad HID reports
Both services can be used without the other, depending on whether you just want to read a device but not send gamepad reports (for volume control for instance)
or send gamepad reports based on values computed by the keyboard.
### Analog Input
To use analog input you must first enable it in `rules.mk`:
```makefile
JOYSTICK_ENABLE= analog
```
An analog device such as a potentiometer found on a gamepad's analog axes is based on a [voltage divider](https://en.wikipedia.org/wiki/Voltage_divider).
It is composed of three connectors linked to the ground, the power input and power output (usually the middle one). The power output holds the voltage that varies based on the position of the cursor,
which value will be read using your MCU's [ADC](https://en.wikipedia.org/wiki/Analog-to-digital_converter).
Depending on which pins are already used by your keyboard's matrix, the rest of the circuit can get a little bit more complicated,
feeding the power input and ground connection through pins and using diodes to avoid bad interactions with the matrix scanning procedures.
### Configuring the Joystick
By default, two axes and eight buttons are defined. This can be changed in your `config.h`:
```c
// Max 32
#define JOYSTICK_BUTTON_COUNT 16
// Max 6: X, Y, Z, Rx, Ry, Rz
#define JOYSTICK_AXES_COUNT 3
```
When defining axes for your joystick, you have to provide a definition array. You can do this from your keymap.c file.
A joystick will either be read from an input pin that allows the use of the ADC, or can be virtual, so that its value is provided by your code.
You have to define an array of type ''joystick_config_t'' and of proper size.
There are three ways for your circuit to work with the ADC, that relies on the use of 1, 2 or 3 pins of the MCU:
* 1 pin: your analog device is directly connected to your device GND and VCC. The only pin used is the ADC pin of your choice.
* 2 pins: your analog device is powered through a pin that allows toggling it on or off. The other pin is used to read the input value through the ADC.
* 3 pins: both the power input and ground are connected to pins that must be set to a proper state before reading and restored afterwards.
The configuration of each axis is performed using one of four macros:
*`JOYSTICK_AXIS_VIRTUAL`: no ADC reading must be performed, that value will be provided by keyboard/keymap-level code
*`JOYSTICK_AXIS_IN(INPUT_PIN, LOW, REST, HIGH)`: a voltage will be read on the provided pin, which must be an ADC-capable pin.
*`JOYSTICK_AXIS_IN_OUT(INPUT_PIN, OUTPUT_PIN, LOW, REST, HIGH)`: the provided `OUTPUT_PIN` will be set high before `INPUT_PIN` is read.
*`JOYSTICK_AXIS_IN_OUT_GROUND(INPUT_PIN, OUTPUT_PIN, GROUND_PIN, LOW, REST, HIGH)`: the `OUTPUT_PIN` will be set high and `GROUND_PIN` will be set low before reading from `INPUT_PIN`.
In any case where an ADC reading takes place (when `INPUT_PIN` is provided), additional `LOW`, `REST` and `HIGH` parameters are used.
These implement the calibration of the analog device by defining the range of read values that will be mapped to the lowest, resting position and highest possible value for the axis (-127 to 127).
In practice, you have to provide the lowest/highest raw ADC reading, and the raw reading at resting position, when no deflection is applied. You can provide inverted `LOW` and `HIGH` to invert the axis.
For instance, an axes configuration can be defined in the following way:
When the ADC reads 900 or higher, the returned axis value will be -127, whereas it will be 127 when the ADC reads 285 or lower. Zero is returned when 575 is read.
In this example, the first axis will be read from the `A4` pin while `B0` is set high and `A7` is set low, using `analogReadPin()`, whereas the second axis will not be read.
In order to give a value to the second axis, you can do so in any customizable entry point: as an action, in `process_record_user()` or in `matrix_scan_user()`, or even in `joystick_task()` which is called even when no key has been pressed.
You assign a value by writing to `joystick_status.axes[axis_index]` a signed 8-bit value (ranging from -127 to 127). Then it is necessary to assign the flag `JS_UPDATED` to `joystick_status.status` in order for an updated HID report to be sent.
The following example writes two axes based on keypad presses, with `KC_P5` as a precision modifier:
//increment the pointer to fetch a new byte during the next loop
reader.current_element++;
}
}
}
```
## Other Examples
In split keyboards, it is very common to have two OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
@ -422,8 +422,8 @@ Where `28` is an unused index from `eeconfig.h`.
|`rgb_matrix_toggle_noeeprom()` |Toggle effect range LEDs between on and off (not written to EEPROM) |
|`rgb_matrix_enable()` |Turn effect range LEDs on, based on their previous state |
|`rgb_matrix_enable_noeeprom()` |Turn effect range LEDs on, based on their previous state (not written to EEPROM) |
|`rgb_matrix_disable()` |Turn effect range LEDs off |
|`rgb_matrix_disable_noeeprom()` |Turn effect range LEDs off (not written to EEPROM) |
|`rgb_matrix_disable()` |Turn effect range LEDs off, based on their previous state |
|`rgb_matrix_disable_noeeprom()` |Turn effect range LEDs off, based on their previous state (not written to EEPROM) |
### Change Effect Mode :id=change-effect-mode
|Function |Description |
@ -431,19 +431,31 @@ Where `28` is an unused index from `eeconfig.h`.
|`rgb_matrix_mode(mode)` |Set the mode, if RGB animations are enabled |
|`rgb_matrix_mode_noeeprom(mode)` |Set the mode, if RGB animations are enabled (not written to EEPROM) |
|`rgb_matrix_step()` |Change the mode to the next RGB animation in the list of enabled RGB animations |
|`rgb_matrix_step_noeeprom()` |Change the mode to the next RGB animation in the list of enabled RGB animations (not written to EEPROM) |
|`rgb_matrix_step_reverse()` |Change the mode to the previous RGB animation in the list of enabled RGB animations |
|`rgb_matrix_increase_speed()` |Increases the speed of the animations |
|`rgb_matrix_decrease_speed()` |Decreases the speed of the animations |
|`rgb_matrix_step_reverse_noeeprom()` |Change the mode to the previous RGB animation in the list of enabled RGB animations (not written to EEPROM) |
|`rgb_matrix_increase_speed()` |Increase the speed of the animations |
|`rgb_matrix_increase_speed_noeeprom()` |Increase the speed of the animations (not written to EEPROM) |
|`rgb_matrix_decrease_speed()` |Decrease the speed of the animations |
|`rgb_matrix_decrease_speed_noeeprom()` |Decrease the speed of the animations (not written to EEPROM) |
|`rgb_matrix_set_speed(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 |
|`rgb_matrix_set_speed_noeeprom(speed)` |Set the speed of the animations to the given value where `speed` is between 0 and 255 (not written to EEPROM) |
|`rgb_matrix_increase_hue()` |Increase the hue for effect range LEDs. This wraps around at maximum hue |
|`rgb_matrix_increase_hue_noeeprom()` |Increase the hue for effect range LEDs. This wraps around at maximum hue (not written to EEPROM) |
|`rgb_matrix_decrease_hue()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue |
|`rgb_matrix_decrease_hue_noeeprom()` |Decrease the hue for effect range LEDs. This wraps around at minimum hue (not written to EEPROM) |
|`rgb_matrix_increase_sat()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation |
|`rgb_matrix_increase_sat_noeeprom()` |Increase the saturation for effect range LEDs. This wraps around at maximum saturation (not written to EEPROM) |
|`rgb_matrix_decrease_sat()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation |
|`rgb_matrix_decrease_sat_noeeprom()` |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation (not written to EEPROM) |
|`rgb_matrix_increase_val()` |Increase the value for effect range LEDs. This wraps around at maximum value |
|`rgb_matrix_increase_val_noeeprom()` |Increase the value for effect range LEDs. This wraps around at maximum value (not written to EEPROM) |
|`rgb_matrix_decrease_val()` |Decrease the value for effect range LEDs. This wraps around at minimum value |
|`rgb_matrix_decrease_val_noeeprom()` |Decrease the value for effect range LEDs. This wraps around at minimum value (not written to EEPROM) |
|`rgb_matrix_sethsv(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 |
|`rgb_matrix_sethsv_noeeprom(h, s, v)` |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
@ -28,7 +28,9 @@ After this, you'll want to use the `tap_dance_actions` array to specify what act
*`ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: Sends the `kc` keycode when tapped once, or toggles the state of `layer`. (this functions like the `TG` layer keycode).
*`ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action.
*`ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
*`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
*~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
* This is deprecated in favor of the Per Key Tapping Term functionality, as outlined [here](custom_quantum_functions.md#Custom_Tapping_Term). You'd want to check for the specific `TD()` macro that you want to use (such as `TD(TD_ESC_CAPS)`) instead of using this specific Tap Dance function.
The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise.
@ -239,3 +239,4 @@ There are a number of DFU commands that you can use to flash firmware to a STM32
*`:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
*`:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
*`:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util.
*`:st-flash` - This allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util.
このページは QMK API の使い方を説明します。もしあなたがアプリケーション開発者であれば、全ての [QMK](https://qmk.fm) キーボードのファームウェアをコンパイルするために、この API を使うことができます。
## 概要
このサービスは、カスタムキーマップをコンパイルするための非同期 API です。API に 何らかの JSON を POST し、定期的に状態をチェックし、ファームウェアのコンパイルが完了していれば、結果のファームウェアと(もし希望すれば)そのファームウェアのソースコードをダウンロードすることができます。
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.
