* add feature_leader_key.md translation
* update based on comment
* set link as lang dir
* update based on comment
* update based on comment
* update based on comment
* Add Via keymap for Contra
* Added Via-enabled keymap
* Changed VENDOR_ID from 0xFEED to 0x4354 (CT)
* Removed unnecessary RGB mappings
* PR changes
* Removed empty via/config.h
* Changed product ID from 0x6060 to 0x0001
* Add files needed to The Via support on Melody 96
* Remove manufacture name from product name
* replace blank key with Transparent keys
* Update keyboards/melody96/rules.mk
* Update keyboards/melody96/keymaps/via/keymap.c
* Change Product ID to "M" + 96
* Update keyboards/melody96/keymaps/via/rules.mk
* add LTO to via's local file
* Update keyboards/melody96/rules.mk
* more stoof
* readme update
* reverting keymap
* re-adding userspace
* new userspace needed
* no want 0 under thumb
* gettin fancier with my knob
* macro fix
* had pins for oled ver
* wait, these are the right pins
* reduntant line
* image fix
* get highest layer every day
* whoops
* correct rev name in json
* a few good catches
* what I had planned
* Replace custom RCTRL implementation with built-in LM
Caveat: sends LCtrl instead of RCtrl
* Enable VIA support in KBD6X keymap
* Disable LTO on ChibiOS boards
* Disable locking support and Magic keycodes for all keymaps
* Organize and annotate rules.mk and config.h files
* Enable Console for Melody96 keymap
* L_RANGE_KEYMAP → LAYERS_KEYMAP
* Revert "Replace custom RCTRL implementation with built-in LM"
This reverts commit 17d706a82d7e31b53cd84efeb9b2ddb9922a2368.
* Set DYNAMIC_KEYMAP_LAYER_COUNT to 3 in Doro67 and Wasdat keymaps
* Enable Bootmagic Lite for all VIA keymaps
* added koy layout to qmk on xd75 board
* added koy keymap for the atreus62 board
* reduced time for autoshift
* added documentation
* changed layer 7 to a tap toggle and adjusted mouse speed a little
* Update keyboards/xd75/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/xd75/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/xd75/keymaps/ScheiklP/koy_common.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_common.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* Update keyboards/atreus62/keymaps/ScheiklP/koy_keys_on_quertz_de_latin1.h
* changed keymap to lowercase name to conform with qmk guidelines
* Update keyboards/xd75/keymaps/scheiklp/rules.mk
remove unnecessary rules
* Update keyboards/atreus62/keymaps/scheiklp/rules.mk
remove unnecessary rules
* moved common files for koy layouts to the users folder and removed empty file
* Update keyboards/atreus62/keymaps/scheiklp/keymap.c
* Update keyboards/xd75/keymaps/scheiklp/readme.md
* Update keyboards/xd75/keymaps/scheiklp/readme.md
* Update keyboards/atreus62/keymaps/scheiklp/readme.md
* Update keyboards/atreus62/keymaps/scheiklp/readme.md
* [kle2jinfo] use min/max instead of if
This is a slight change.
Before, the key_skel would keep the invalid value for future keys.
I think this is what was actually intended.
* [kle2info] calculate x
x is the current_x * key_size + (key_size/2)
y is the current_y * key_size + (key_size/2)
no reason to track both
* Improve stock bootloader list
* Switch version numbers on USB64/128 bootloaders
* Unix line endings for PS2AVRGB bootloader
* Update PS2AVRGB bootloader to 1.0.1
* Also mention bootloader rule
* Didn't need to change the links
This commits add the SH_OS keycode, which works similarly to one shot
layers:
* while pressed, the keyboard is swapped
* if no keys were pressed while it was pressed, the next key press is
swapped
SH_OS also supports chaining with one shot layers:
OSL(x) + SH_OS + key interprets the key press on the oneshot layer.
The ONESHOT_TIMEOUT setting used by one shot keys and layers is also
used by oneshot swap hands. In the above chaining scenario the timeout
of the oneshot layer is reset when swap hands is activated.
Resolves#2682
* Allow 16 lighting layers
* Require #define RGBLIGHT_LAYERS_16 to enable 16 layers
* Override RGBLIGHT_MAX_LAYERS to set maximum number of lighting layers
* Enforce lower bound on RGBLIGHT_MAX_LAYERS
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
* Fix an error in the check for valid RGBLIGHT_MAX_LAYERS
* Don't use bitfield / PACKED, as it causes bloat
* Update documentation re: up to 32 lighting layers
* Run cformat
* Add note about increasing FW size in docs/config_options.md
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Remove no-longer-valid comment
* Add doc note that split sync will be slower
Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Improve security by eliminating the use of well-known names.
* Add an additional $ so the shell expands $TMP1 and $TMP2
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Added MACLOCK macro
Added my MACLOCK macro to my Atreus keymap.
* Updated comments & readme
Documented where in the layout I added the MACLOCK macro.
* Updated with my super16 version for my keypad
* Added my folder to super16
* Set max LED brightness to 50%
* Added custom keycodes for enter/shift+enter and copy/paste on one key
* Fixed the boot up layer color
* Renamed folder
* Revert changes to root super16 files
* Update keymap config.h and rules.mk files
* Restore deleted 15game keymap files
* Corrected the hold keycode for CCCV
* Removed unnecessary comments
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/keymap.c
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/config.h
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Update keyboards/1upkeyboards/super16/keymaps/nblyumberg/keymap.c
Co-Authored-By: ridingqwerty <george.g.koenig@gmail.com>
* Rewriting the layer color functionality
* Revisions
* Fixed the layer switching
* Fixed the default layer color problem
* Added a function suggested by Drashna but it won't compile
* Cleaned up the code for PR
* Removed unnecessary define for layer colors
Co-authored-by: ridingqwerty <george.g.koenig@gmail.com>
* Implement momentarily blink of lighting layers
* Refactor spidey3 userspace to use rgb layer blink
* Remove un-necessary line from example in documentation
* Revert "Refactor spidey3 userspace to use rgb layer blink"
This reverts commit 831649bb680c41c6d663ae6fa86d13f4f8bebdd8.
* Adds a missing bit of documentation about lighting layer blink
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update docs/feature_rgblight.md per suggestions
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* cformat, as suggested
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Invert UC_MOD/UC_RMOD direction when Shift is held
Also use MOD_MASK_SHIFT in process_rgb.c
* Allow audio to be played for UC_MOD, UC_RMOD keycodes as well
* Fix signedness bug in reverse input mode cycling
* Misc formatting in process_unicode_common.c
* Address clang-format issues
* Make decode_utf8 helper function file-local (static)
* [Keyboard] Added D48 keyboard.
* Updated README.
* Cleanups.
* Moved d48 to handwired/
* Added link to build process album.
* Coding conventions cleanups.
* Added DS1307 RTC!
* Minor cleanups.
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Minor refactoring.
* Readme fix.
* Moved leftover keymap-specific code from keyboard space into keymap.
* Added encoder button pins to extra matrix row.
* Updated README, updated pinout & cleaned up the glcdfont
* Apply suggestions from code review
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update config.h
* Apply suggestions from code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Added default keymap. Refactored existing keymap.
* Update keyboards/handwired/d48/README.md
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Co-Authored-By: Joel Challis <git@zvecr.com>
* Minor alignment fix.
* Update keyboards/handwired/d48/glcdfont_d48.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Changes as per PR.
* Apply suggestions from code review
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>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* initial user directory
* fix missing endif in vi mode
* fix includes per drashna and a few typos. I have not tested the userspace keymap, it is just there to help keep the user space and keymap in sync
* move babblepaste docs to md format
* clean up block quotes
* TIL clang-format - miles2go userspace
* Add TENKI keyboard
Add TENKI keyboard, default keymap and via keymap
* Minor Update Readme.md
Change description of hardware supported
* change layout name
change layout name from ortho_20 to ortho_5x4
* Fix invalid format in info.json
Fix invalid format in info.json
* Fix invalid format
* Fix formatting
Fix formatting tenki.h
* Fix formatting in keymap.c
Fix formatting in keymap.c
* Add new line at EOF info.json
Add new line at EOF
* Fix formatting
* Fix formatting
* Update rules.mk
Fix Formatting
* Initial
* update json, added basic oled config, updated matrix to correct rotary location
* disable oled by default
* Tuned oled for release
* Completed OLED function implementation
Correct spelling error in readme
* Fixed image in readme
* Should not be in this branch
* Incorporating recommended changes by zvecr
* Update keyboards/le_chiffre/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/le_chiffre/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Keyboard: add treeadstone48
* rename layout defines
* Use of pragma once
* move common include code
* fixed info.json
* change keymap layout from kc to normal
* fix alpha revision keymap
* fixed info.json
* remove USE_Link_Time_Optimization
* Add keyboard firmware of treadstone32lite
* fixed by the review
* I used to set this to a per-keymap setting, so I'll undo it.
* Community layout support for KBD67 hotswap
* Community layout support for KBD67 rev1
* Community layout support for KBD67 rev2
* Move bcat's KBD67 hotswap layout to community
* New keymap layout for dztech/dz65rgb/keymaps
* New keymap layout for dztech/dz65rgb/keymaps
- Conding conventions fixes
* Fix typo in Leader Key table
* PR #8199 Feedback Commit #1
* Fixed data types and function names - Simplified accent macros by removing repetition - Added selection wrap macros - readme.md doc updated with changes
* PR #8199 second feedback commit - Clarified function names, variables names and comments
* Fix: accent output fix _grave <==> _circumflex
* dry fixes on led set_color with hsv and led blinking code blocks
* my new layout, draft one, untested.
* updated mapping to include more keys
* updated layout name to be more descriptive. Updated readme with more information.
* added more info to the readme and spellchecked it.
* Added the Json for the keyboard layout images and updated the readme to reflect this.
* Updated Image link
Updated Image link so that it links to the correct place
* updated copyright info to include MY name.
* Updated copyright attribuatation to include the author of the file I modified.
* added the backlighting key back to the adjust layer so that it is usable.
* updated the name of the keymap to match my github name.
* Mitor Tweaks
Updating Dvorak keymap to change location of Slash and Backslash
to positions more in line with my 12x5 and similar ortho layouts
* Fixed readme.md
Tidied up the readme and make some minor changes.
* Adding atreus config file
Adding a config file for my Atreus keyboard. This is to help with
the keychatter issues I've been having on my Atreus.
* Changes as requested per @zvecr
Added `#pragma once` to beginning of config.h file as requested
by @zvecr.
* Working on proto
* Start adding VIA support
* Apply suggestions from code review
Removed redundant comments and fixed typos
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-Authored-By: Joel Challis <git@zvecr.com>
* Delete useless config.h
As per code review
* Delete elongate.c
As per code review
* Updated readme.md
* Update keyboards/acheron/elongate/keymaps/default/keymap.c
As per code review
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Removed RGB_MODE_TEST definition and substituted for RGB_M_T
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Reverted changes to alice.h
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Update info.json
* Update via/keymap.c
Co-Authored-By: Ryan <fauxpark@gmail.com>
* Solve compiling issue for via keymap
* Add botmagic support and remoce console_enable
Co-Authored-By: Joel Challis <git@zvecr.com>
* Update keyboards/acheron/elongate/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/keymaps/via/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/acheron/elongate/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Gondolindrim <alvaro.augusto.volpato@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* Refactor to use mpaland/printf
* trim firmware size
* remove keymap changes
* run clang format
* Fixup after rebase
* fix up git-submodule command for printf
* Branch point for 2020 May 30 Breaking Change
* audio-configuration: template: audio_avr.c does NOT default to C6
not on its own, it needs a pin configured per define in config.h for audio to actually work
otherwise only parts of the code are included in the firmware, wasting space and possibly breaking builds because auf hitting the firmware-size limits
* audio-configuration: strip comment to bare essentials
Co-Authored-By: Ryan <fauxpark@gmail.com>
* revert future change
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Johannes <you@example.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: zvecr <git@zvecr.com>
* Added raw hid feature documentation page
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/features.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* added feature_rawhid.md to _summary.md in docs
* fixed _summary.md order
* Update docs/feature_rawhid.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update feature_rawhid.md
Removed the useless bit about finding usage page and usage.
* Update feature_rawhid.md
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Update docs/feature_rawhid.md
Co-Authored-By: Nick Brassel <nick@tzarc.org>
* Remove teensy client, small origanization fixes
* Fixed merge conflicts
Removed features.md
Updated _summary.md with new format and added RAW HID entry under Software Features
* Added rawhid feature page
Messy is what you get when you don't do things right the first time
Co-authored-by: fauxpark <fauxpark@gmail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* add 'togglePin' conveniance function
for AVR and chibios
* drop outmost parantheses
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* toggle pin on avrs
toggle a pin configured as output by writing the corresponding bit to the PIN register
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
* togglepin: add documentation for newly added function
* Update docs/internals_gpio_control.md
Co-Authored-By: Konstantin Đorđević <vomindoraan@gmail.com>
* on AVR: use PORTD to toggle the output
... since not all MCUs support toggling through writing to PIN
Co-Authored-By: Ryan <fauxpark@gmail.com>
Co-authored-by: Johannes <you@example.com>
Co-authored-by: Konstantin Đorđević <vomindoraan@gmail.com>
Co-authored-by: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* id80: Transpose matrix to use faster COL2ROW routines
Even the standard QMK matrix_scan() function can give about 2 times
higher scan rate (if compiled with optimizations enabled) if the COL2ROW
matrix layout is used instead of ROW2COL. Although the ID80 PCB is
wired using the ROW2COL matrix layout, it is possible to transpose the
matrix from the QMK standpoint, so that "columns" would correspond to
horizontal connections, and "rows" would correspond to (mostly) vertical
connections; in this case the matrix could be handled as if it had the
COL2ROW layout.
The matrix layout change makes the older VIA JSON layout definition
incompatible, but the corresponding JSON was not yet accepted to the VIA
repository, so it should still be safe to make this change.
* id80: Remove obsolete comments
@ -13,18 +13,17 @@ QMK requires Python 3.6 or greater. We try to keep the number of requirements sm
If you have installed [Homebrew](https://brew.sh) you can tap and install QMK:
```
brew tap qmk/qmk
brew install qmk
brew install qmk/qmk/qmk
export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
```
### Install Using easy_install or pip :id=install-using-easy_install-or-pip
### Install Using pip :id=install-using-easy_install-or-pip
If your system is not listed above you can install QMK manually. First ensure that you have python 3.6 (or later) installed and have installed pip. Then install QMK with this command:
If your system is not listed above you can install QMK manually. First ensure that you have Python 3.6 (or later) installed and have installed pip. Then install QMK with this command:
```
pip3 install qmk
python3 -m pip install qmk
export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
@ -191,7 +191,12 @@ If you define these options you will enable the associated feature, which may in
* `#define RGBLIGHT_ANIMATIONS`
* run RGB animations
* `#define RGBLIGHT_LAYERS`
* Lets you define [lighting layers](feature_rgblight.md) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
* Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
* `#define RGBLIGHT_MAX_LAYERS`
* Defaults to 8. Can be expanded up to 32 if more [lighting layers](feature_rgblight.md?id=lighting-layers) are needed.
* Note: Increasing the maximum will increase the firmware size and slow sync on split keyboards.
* `#define RGBLIGHT_LAYER_BLINK`
* Adds ability to [blink](feature_rgblight.md?id=lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
`EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = spi` | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
`#define STM32_ONBOARD_EEPROM_SIZE` | The size of the EEPROM to use, in bytes. Erase times can be high, so it's configurable here, if not using the default value. | Minimum required to cover base _eeconfig_ data, or `1024` if VIA is enabled.
Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes.
@ -50,8 +50,8 @@ LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing
````
This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`.
It is advised to clear the display before use.
To do so call `lcd_clrsrc()`.
To do so call `lcd_clrscr()`.
To now print something to your Display you first call `lcd_gotoxy(column, line)`. To go to the start of the first line you would call `lcd_gotoxy(0, 0)` and then print a string with `lcd_puts("example string")`.
There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
Raw HID allows for bidirectional communication between QMK and the host computer over an HID interface. This has many potential use cases, such as switching keymaps on the fly or changing RGB LED colors and modes.
There are two main components to getting raw HID working with your keyboard.
## Keyboard firmware
The implementation is fairly straightforward for the firmware.
In your `rules.mk` add:
```make
RAW_ENABLE = yes
```
In your `keymap.c` include `"raw_hid.h"` and implement the following:
// Your code goes here. data is the packet received from host.
}
```
The `"raw_hid.h"` header also declares `void raw_hid_send(uint8_t *data, uint8_t length);` which allows sending packets from keyboard to host. As an example, it can also be used for debugging when building your host application by returning all data back to the host.
`raw_hid_receive` can receive variable size packets from host with maximum length `RAW_EPSIZE`. `raw_hid_send` on the other hand can send packets to host of exactly `RAW_EPSIZE` length, therefore it should be used with data of length `RAW_EPSIZE`.
Make sure to flash raw enabled firmware before proceeding with working on the host side.
## Host (Windows/macOS/Linux)
This is the more complicated part as it will require some digging.
To connect your host computer to your keyboard with raw HID you need four pieces of information about your keyboard:
1. Vendor ID
2. Product ID
3. Usage Page
4. Usage
The first two can easily be found in your keyboard's `config.h` in the keyboard's main directory under `VENDOR_ID` and `PRODUCT_ID`. **Usage Page** is **`0xFF60`** and **Usage** is **`0x0061`**.
### Building your host
You can build your host using any language that has an available HID implementation library if you don't wish to make your own. The ones we know of for popular languages are:
This is not an exhaustive cross-platform list but should get you started. There are no special requirements for using raw HID so any HID library should work.
Now that you have all four pieces of information required to open HID interface to your keyboard. All you need to do is use your library's available functions to open the device with its ID parameters.
Note that Vendor ID and Product ID are not actually required to open the device. They are used only to filter to a specific device out of the many HID devices you have plugged in. Many libraries will give you the option to open the device using Product Name or Manufacturer Name instead, `node-hid` being a prime example. This will create issues for devices with builtin USB Hub or any extra HID interfaces where you will have multiple interfaces with the same name or from the same manufacturer. The Vendor ID together with Product ID create a unique designation to a single interface and will not exhibit this problem. Therefore, even if your library doesn't require you to, it is best to use them to avoid issues.
Unlike Vendor ID and Product ID though, Usage Page and Usage are necessary for successful communication.
It should go without saying that regardless of the library you're using, you should always make sure to close the interface when finished. Depending on the operating system and your particular environment there may be issues connecting to it again afterwards with another client or another instance of the same client if it's not explicitly closed.
|`rgb_matrix_is_enabled()` |Gets current on/off status |
|`rgb_matrix_get_mode()` |Gets current mode |
|`rgb_matrix_get_hue()` |Gets current hue |
|`rgb_matrix_get_sat()` |Gets current sat |
|`rgb_matrix_get_val()` |Gets current val |
|`rgb_matrix_get_hsv()` |Gets hue, sat, and val and returns a [`HSV` structure](https://github.com/qmk/qmk_firmware/blob/7ba6456c0b2e041bb9f97dbed265c5b8b4b12192/quantum/color.h#L56-L61)|
|`rgb_matrix_get_speed()` |Gets current speed |
|`rgb_matrix_get_suspend_state()` |Gets current suspend state |
Check out [this video](https://youtube.com/watch?v=VKrpPAHlisY) for a demonstration.
@ -103,8 +104,8 @@ Note: For versions older than 0.6.117, The mode numbers were written directly. I
Use these defines to add or remove animations from the firmware. When you are running low on flash space, it can be helpful to disable animations you are not using.
By including `#define RGBLIGHT_LAYERS` in your `config.h` file you can enable lighting layers. These make
it easy to use your underglow LEDs as status indicators to show which keyboard layer is currently active, or the state of caps lock, all without disrupting any animations. [Here's a video](https://youtu.be/uLGE1epbmdY) showing an example of what you can do.
By default, 8 layers are possible. This can be expanded to as many as 32 by overriding the definition of `RGBLIGHT_MAX_LAYERS` in `config.h` (e.g. `#define RGBLIGHT_MAX_LAYERS 32`). Please note, if you use a split keyboard, you will need to flash both sides of the split after changing this. Also, increasing the maximum will increase the firmware size, and will slow sync on split keyboards.
To define a layer, we modify `keymap.c` to list out LED ranges and the colors we want to overlay on them using an array of `rgblight_segment_t` using the `RGBLIGHT_LAYER_SEGMENTS` macro. We can define multiple layers and enable/disable them independently:
@ -115,12 +115,18 @@ The simplest and quickest way to get things back to normal is to flash only a bo
You can find the stock bootloaders in the [`util/` folder](https://github.com/qmk/qmk_firmware/tree/master/util). Be sure to flash the correct bootloader for your chip:
* [`Pro Micro`](https://github.com/sparkfun/Arduino_Boards/blob/master/sparkfun/avr/bootloaders/caterina/Caterina-promicro16.hex) - The default bootloader for Pro Micro controllers
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU =` line will have the value you need. It may differ between different versions of the board.
If you're not sure what your board uses, look in the `rules.mk` file for the keyboard in QMK. The `MCU` and `BOOTLOADER` lines will have the value you need. It may differ between different versions of the board.
original document: 0.8.134:docs/feature_leader_key.md
git diff 0.8.134 HEAD -- docs/feature_leader_key.md | cat
-->
もしあなたが Vim を使ったことがある場合、リーダーキーは何であるかを知っています。そうでなければ、素晴らしい概念を発見しようとしています。:) 例えば、Alt+Shift+W を押す(3つのキーを同時に押す)代わりに、キーの_シーケンス_を押すことができたらどうでしょう?つまり、特別なモディファイア (リーダーキー)を押して、続けて W と C を押すと (単純にキーを高速に繋げます)、何かが起こります。
@ -71,10 +71,22 @@ On the other hand, you can change `layer_state` to overlay the base layer with o
### Layer Precedence and Transparency
Note that ***higher layer has higher priority on stack of layers***, namely firmware falls down from top layer to bottom to look up keycode. Once it spots keycode other than **`KC_TRNS`**(transparent) on a layer it stops searching and lower layers aren't referred.
Note that ***higher layers have higher priority within the stack of layers***. The firmware works its way down from the highest active layers to look up keycodes. Once the firmware locates a keycode other than `KC_TRNS` (transparent) on an active layer, it stops searching, and lower layers aren't referenced.
You can place `KC_TRANS` on overlay layer changes just part of layout to fall back on lower or base layer.
Key with `KC_TRANS` (`KC_TRNS` and `_______` are the alias) doesn't has its own keycode and refers to lower valid layers for keycode, instead.
____________
/ / <---Higherlayer
/ KC_TRNS //
/___________// <---Lowerlayer(KC_A)
/___________/
In the above scenario, the non-transparent keys on the higher layer would be usable, but whenever `KC_TRNS` (or equivalent) is defined, the keycode (`KC_A`) on the lower level would be used.
**Note:** Valid ways to denote transparency on a given layer:
* `KC_TRANSPARENT`
* `KC_TRNS` (alias)
* `_______` (alias)
These keycodes allow the processing to fall through to lower layers in search of a non-transparent keycode to process.
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.