* 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>
* Fix the LED's ID of ISSI for MJ64 REV2
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>
* Add support VIA support to v60 Type R
* Update keyboards/v60_type_r/config.h
Revert combining product and manufacturer
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/v60_type_r/keymaps/via/keymap.c
Remove empty `led_set_user` function
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/v60_type_r/rules.mk
Don't enable bootmagic lite
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add missing empty layers for VIA
* Update keyboards/v60_type_r/rules.mk
Fix comment formatting
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update the VENDOR_ID
Co-authored-by: Ryan <fauxpark@gmail.com>
* added Pursuit40 PCB for Panc40
Pursuit40 is another PCB option for the Panc40 that was sold on Panc.co/store
* added via support
* Apply suggestions from code review
* Apply suggestions from code review
* deleted extra row in VIA keymap
sorry about that - extra row was a holdover from a copy-paste
* deleted commented extra row
extra row was a holdover from a copy-paste
* updated VIA keymap
empty layer added
* fixed bug
* Apply suggestions from code review
committed
* Improve Pointing Device report sending
* Hide old report behind preprocessors too
* put host_mouse_send() in curly brackets
* Remove POINTING_DEVICE_ALWAYS_SEND_REPORT functionality
* Fix typo
* fix function ref in docs
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Add lck75 keyboard
A 75% THT keyboard with an OLED and rotary encoder
* added info.json
* fixed rules.mk
* changed vendor id
* Update keyboards/lck75/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/lck75/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/lck75/keymaps/default/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/lck75/keymaps/default/keymap.c
moved code to the rules.mk folder
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update rules.mk
moved oled driver enable to rules.mk code
* Update keyboards/lck75/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update oled.c
id like to keep the copyright there as it's my friend that helped me with the OLED specifically. also updated the old_task_user
* Update keyboards/lck75/oled.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lck75/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lck75/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lck75/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update rules.mk
* merged oled.c code into keymap.c file
tested and works correctly on my board
* merged code from this file into the keymap.c file
this file is no longer needed
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fix DEBUG_MATRIX_SCAN_RATE on chibiOS when console is enabled
* update type in dprintf
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add SCRAMBLE
* Make requested changes to PR
* Add all layers to VIA keymap
Implement drashna's PR feedback in order to avoid random data within the layers in VIA.
* Make requested changes to PR
Implement fauxpark's PR feedback to clean up readme.md and rules.mk.
* Make changes based on PR feedback
-Changed VIA layers to enum
-Added info on how to enter the bootloader to readme
* Initial attempt at allowing keyboards to indicate what features they do not support
* try to use a for loop instead
* Update disable_features.mk
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add a few more features
* remove my test fixture
* disable things that make all:all suggested"
Co-authored-by: Zach White <skullydazed@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* First version of keymap
* cleaned up code, made some tweaks, added readme
* extended oled timeout
* resolved final issues, all features functional
* added some leader-key combos
* added missing RGB keys to layout diagram
* removed lines for older elite-c v3
* make filename lowercase
* add old update interval
* fix spacing
* Initial support for Durgod K320 with BootMagic Lite
- Adding missing files
- Add Unicode Map Support & new user keymap
- Remove personalized features from Default keymap
- Added Unicode Map to both Default and kuenhlee keymap.c
- Updated readme.md
- Added additional Fn Shortcut keys
* Additional support for Durgod K320
- Simplifying default keymap
- Renaming durgod_k320 => durgod/k320
- Removing copy of ST_NUCLEO64_F070RB from K320. Replacing with local board.h
- Adding Mac keyboard layout for K320 as alternative via Fn+F12
- Implementing Windows Key lock on K320
- Cleaning up duplicated core functionality
- Adding default_toggle_mac_windows keymap with:
- Ability to toggle between Windows and MacOS layout
- Mac Media Lock functionality.
* Updating K320 keymap readme
Co-authored-by: kuenhlee <eos.camera.lee@gmail.com>
* Knobgoblin keyboard initial commit
New macropad initial commit. Keyboard and keymap
* corrected bracket and layout name
* attempting info file fix again
* info file line 33 hanging comma fix
* Update keyboards/knobgoblin/config.h
per fauxpark review
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/knobgoblin/readme.md
per fauxpark review
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/knobgoblin/readme.md
per fauxpark review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
The LED anodes of the pockettype are connected to the bus voltage when a
pro micro is used, but other controllers like the Elite-C (v4) connect this
pin to GPIO B0. This means that LEDs do not work by default for those
controllers.
This commit implements a fix for that by setting the B0 pin high.
* Add RGB Matrix support for Mark 65 keyboard
* Update drive LED count
* Removed unnecessary define line
* Corrected typo
Co-authored-by: filterpaper <filterpaper@localhost>
* initial commit Dawn keyboard
* fixing some matrix
* final tweaks to keymaps and info.json layout
* fix info.json missing delimiter
* missing elements in info.json layout, resolved through lint
* fixed missing link image in readme
* Update keyboards/mechstudio/dawn/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: David <david@tarpit.be>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fix minor typo in "General FAQ"
"want to do brand it with QMK" -> "want to brand it with QMK"
* Reword some of "Debugging FAQ" & "Miscellaneous FAQ".
Mostly grammatical wording of some parts and missing capitalization
* Initial commit on new clean branch. Testing out functionality of oled and encoder for default features.
* Cleaned up the initial push and removed the fancy keymap until the extra features and functionality can be tested and made more user friendly.
* Cleaned up the readme some more, compiled and tested both default and via keymaps, and did another round of checks to prepare for starting the PR.
* Cleaning up the keymap to meet expected formatting in a couple places and also adding in the TAP_CODE_DELAY after newly encoutnered encoder issues and inconsistencies.
* Initial commit of branch specifically for implementing the more complicated fancy keymap as I expect the main PR to be approved first.
* testing bongo cat out
* Progress with intended OLED behavior. Needs to be cleaned up still.
* Cleaned up bongocat and added WPM display on it.
* Almost there. Need to rethink the layer checking in encoder.
* Fixing all the merge issues I didn't check before doing the last commit. Learn from my mistakes, check your commits.
* Fixed and updated fancy firmware and bongocat firmware.
* Updating license year since I will be doing a PR anyway.
* Update keyboards/mechwild/mercutio/keymaps/fancy/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* split config.h for each variant
* split rules.mk for each variant
* split source and header files for each variant
* move keymaps to the appropriate variant
* update keyboard readme
* update keymap readmes
* differentiate Staggered and Ortho USB Device Strings
* clean up formatting in info.json
* split info.json files for each variant
* break up the info.json for readability
* correct key positioning and board dimensions
* correct key object sequences
* add weak encoder function to keyboard level
Allows Configurator-compiled firmware to have encoder functionality.
* add variant-specific readme files and bootloader instructions
* QMK Configurator layout support for Pinky
3-row and 4-row versions
* refactor default keymaps
- use an enum for layer names
- remove redundant definitions
- qmk cformat pass
- modify pinky/4 via keymap to mirror pinky/4 default functionality
* remove LAYOUT_kc macros
This usage is not endorsed by QMK as it has been found to be confusing to novice users.
* add VIA support to pinky/3
* update config.h files
Removes unnecessary definitions for Backlight, RGB Underglow, Magic config and MIDI.
* update main rules.mk file
Updates the rules.mk file to match the formatting of the current QMK-provided template. Removes sample bootloader comments, feature rules that are no longer included in the template, and updates the in-line comments.
* update and split keyboard readme
Updates the main readme file's formatting, adds instructions to access bootloader mode, and adds more specific readmes for each version.
* add line breaks between rows in the info.json files
* rename layout macros for Community Layout forward compatibility
The layouts of the Pinky3 and Pinky4 aren't currently Community Layouts, but support for them could be added with a rules.mk edit should the layouts be added to QMK.
* Update other keyboards for rgb matrix changes
* Remove customized bootmagic code
* Fix corne layout compilation error
* Fix compiler errors with all keymaps
* Add Simple Visualizer for ergodox infinity
* Fix compile issue with Corne
* Fix keymap stuff
* Add alias for mouse layer
* Add Halmak Keyboard layout
* Updates for Kyria
* Add support for oled interval
* Change RGB stuff
[CHANGE] Fix coexistence issues
* Fix rgb_stuff
* Add custom ploopyco mouse keymap
* Decrease default dwell time
* Updates based on last breaking changes update
* Disable command on dactyl
* Update ergodox to use proper commands for rgb matrix indicators
* Update all rgb matrix indicator functions
* Update rules for dactyl-manuform
* Reduce wait time for mouse layer off event
* Add more info to logger
* Add wrappers for get_tapping term
* Move version.h include into only file that actually needs it
* Update rgb sleep stuff
* Update key print function
* Change DM keymap settings
* Change pin for DM Manuform
* Add Proton C stuff for Corne keymap
* more arm corne tinkering
* Even more arm stuff for corne
* Cleanup corne stuff
* redirect default keymap to drashna
because I am a very bad man
* change corne rgb priority
* Update tractyl manuform to not conflict
* Add more secret stuff
* more dactyl tweaks
* Add more options to split transport
* Changes of oled support
* Change split settings
* Improve keylogger formatting more
* tweak oled stuff
* Oled and such tweaks
* Reduce brightness due to leds
* Decrease brightness more
* Only run layer code if master
* info.json: human-friendly formatting
* info.json: update key object labels
Some of the characters in the original file don't play nicely with `qmk info -l` on Windows.
* info.json: correct key object order
* exclude 'helix/rev3_4rows' from CI
Since helix/rev3_4rows is almost the same as helix/rev3_5rows, there is no point in checking with travis-ci.
* include 'helix/pico/back' to CI
helix pico and helix rev2 are still available. I would like to check both by travis-ci, but here I will add a check only for helix pico.
* first pass
* firmware firmware?
* Split out debug + testing docs
* tidy up duplicate css
* Add extra info to debug example
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add support for bigknob
Add support for bigknob macropad
* corrected files
* Apply suggestions from code review
Co-authored-by: Joel Challis <git@zvecr.com>
* corrected tap dance
* Update config.h
* correct image link
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* added GPL headers
* Update readme.md
* update rules to disable tap dance
* remove tap dance
* Update rules.mk
trying to get to pass travis test
* Update rules.mk
remove tap dance
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
With MAJOR_MODE (= major scale), keys in one octave is not 12 but 7.
To solve this problem, change divisor number from 12 to 7 at %(Modulo) and /(Division).
NOTE:
The last 12 represents half step keys in one octave for pitch calculation.
* Add keyboard: Mesa TKL
* Fix image link in readme
* Update keyboards/mesa/mesa_tkl/mesa_tkl.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/mesa/mesa_tkl/rules.mk
White space changes
Co-authored-by: Ryan <fauxpark@gmail.com>
* Replace tabs with spaces per C coding conventions.
* Update keyboards/mesa/mesa_tkl/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* new repo: create cmm.studio folder, add saka qmk firmware
new folder for cmm.studio line up keyboard
added saka68 keyboard qmk and via firmware support
* Update keyboards/cmm.studio/saka68/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cmm.studio/saka68/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cmm.studio/saka68/keymaps/via/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cmm.studio/saka68/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* fix on keymap, readme
fix on keymap, readme
* Update keyboards/cmm.studio/saka68/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cmm.studio/saka68/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* update vendor name with _ instead of .
update vendor name with _ instead of .
* Update readme.md
change the make format
* Update keyboards/cmm_studio/saka68/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* deleted some files from cmm.studio, changes to cmm_studio
deleted some files from cmm.studio, changes to cmm_studio
* Update readme.md
make command changed
* Update keyboards/cmm_studio/saka68/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update readme.md
added pic for pcb
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update keyboards/cmm_studio/saka68/config.h
tested and does work now. deleting these lines
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update keyboards/cmm_studio/saka68/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update readme.md
added use physical reset button instruction
* change to the cmm saka folder
making the changes to cmm saka firmware
seperated solder version firmware and hotswap version firmware
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* Update readme.md
* change to the cmm saka hotswap folder
Co-authored-by: Ryan <fauxpark@gmail.com>
* feat(kyria): new keymaps with KC_LGUI on another key
add also possibility to scroll with encoder and finally play with olded
screen to replace default kyria logo by Magic the Gathering mana color
icon.
* Update keyboards/kyria/keymaps/benji/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add magic logo
* add mouse button
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add support for --clean to compile and flash
* compile standalone JSON keymaps without polluting the tree
* Add support for passing environment vars to make
* make flake8 happy
* document changes to qmk compile and flash
* add -e support to json export compiling
* Fix python 3.6
* honor $MAKE
* add support for parallel builds
* add byte order bgr for ws2812
* update docs for driver change
* Update ws2812_driver.md
* Update docs/ws2812_driver.md
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* WIP working on new keymap
* tweaking keymap
* updated keymap
* cleaned up a little bit
* New preonic keymap
* my preonic keymap
* added mac layout
* preonic map update
* cleaning up old repo
* cleaning up to match upstream
* more cleanup
* removing old keymaps
* cleaned up commit history for bm60poker via support
* cleaned up via keymap
* fixed copywrite
Co-authored-by: Peter Peterson <ppeterson@noao.edu>
* 1st trial on 1_2
* remove keymaps/default/km_default.c
* fix cool836A.h
* fix keymap.c into 3x12
* rename to cool836a (not 'A')
* remove cool836A (not a)
* remove backslashes at keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* update keymap.c (add licence)
* Update keyboards/cool836a/keymaps/default/readme.md
removed "<br>" in line 2
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cool836a/keymaps/default/readme.md
remove "<br>" in line 4
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cool836a/keymaps/default/readme.md
remove "<br>" in line 8
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cool836a/cool836a.h
remove cool836a.h line 30:36
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initialize domnantas layout
* Update oled status display
* Layout and oled changes
* Updates to keymap
* Add F keys and page moves
* Add media keys, rearrange home and end
* Add instructions
* Swap backspace and enter
* Remove unnecesary Enter keymap
* - Change display timeout
- Update minus sign to work on both English and Lithuanian layouts
* Add copyright header
* Replace static strings with PSTR
* Update keyboards/lily58/keymaps/domnantas/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lily58/keymaps/domnantas/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lily58/keymaps/domnantas/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lily58/keymaps/domnantas/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/lily58/keymaps/domnantas/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add VIA support
made changes to add VIA support for the CA66
- added VIA keymap.c, readme.md, rules.mk
- changes made to main rules.mk to keep firmware size down (mousekey_enable = no; backlight_enable = no)
- changed VENDOR_ID in config.h from 0xFEED to 0x504B (PK)
* Minor changes to CA66 for VIA support
edited keymap info
enabled backlight
* Update vendorID
Change to vendorID to remove conflict with previously chosen vendorID already in use
* Update keyboards/playkbtw/ca66/rules.mk
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/playkbtw/ca66/keymaps/via/readme.md
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/playkbtw/ca66/keymaps/via/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
* add Hub20 support
* Keymap formatting cleanup
Co-authored-by: Ryan <fauxpark@gmail.com>
* Delete bootloader_defs.h as no longer required
* Correct make / flashing example
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* new keymap
* Update keyboards/primekb/prime_e/keymaps/gwillad/keymap.c
use a more concise pin setting method
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Adam Gwilliam <agwilliam@yaharasoftware.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* [Keymap] own Lily58 keymap
Signed-off-by: Christian Eiden <christian@eiden.ch>
* adjustments of personal keymap
Signed-off-by: Christian Eiden <christian@eiden.ch>
* added urbanvanilla keymap
Urbanvanilla's keymap for massdrop/alt keyboard
adds in an idle timer to turn off RGB after set amount of time.
poor unsuccessful attempt at replicating a velocikey like functionality.
Grave escape is enabled on ESC.
* Update readme.md
* updating documentation
* Create readme.md
* restoring default documentation
* update with review changes implemented
removed unnecessary lines and files.
increased wait_us() parameter to 40 as was still getting chatter at 20.
removed some code for the terrible rudimentary attempt at velocikey for rgb matrix
* Update matrix.c
* Revert "Merge pull request #3 from urbanvanilla/dev_branch"
This reverts commit deb55d797a4629965c990ab507251489c578573d, reversing
changes made to ba8817356f6c0881cf7f3214f7f1ebd31febceb5.
* Update keymap.c
* added urbanvanilla keymap
Urbanvanilla's keymap for massdrop/alt keyboard
adds in an idle timer to turn off RGB after set amount of time.
poor unsuccessful attempt at replicating a velocikey like functionality.
Grave escape is enabled on ESC.
* Update readme.md
* updating documentation
* Create readme.md
* restoring default documentation
* update with review changes implemented
removed unnecessary lines and files.
increased wait_us() parameter to 40 as was still getting chatter at 20.
removed some code for the terrible rudimentary attempt at velocikey for rgb matrix
* Update matrix.c
* Revert "Merge pull request #3 from urbanvanilla/dev_branch"
This reverts commit deb55d797a4629965c990ab507251489c578573d, reversing
changes made to ba8817356f6c0881cf7f3214f7f1ebd31febceb5.
* Delete matrix.c
* Update keyboards/massdrop/alt/keymaps/urbanvanilla/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keymap.c
* Update keymap.c
* Update keyboards/massdrop/alt/keymaps/urbanvanilla/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add bongo cat animation
* Map all keys on base layer
... to make it easier to test newly built keyboards. The encoders
are optional and can be placed in different locations.
* Fix Torn in QMK configurator
This removes additional variables defined in the keymap.c file, so
that the default firmware can be compiled by the configurator.
Co-authored-by: Richard Titmuss <richardt@spotify.com>
* init
init
* Update keyboards/hp69/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/hp69/keymaps/via/rules.mk
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/hp69/rules.mk
Co-authored-by: Joel Challis <git@zvecr.com>
* re-added audio support
re-added audio support
* Update keyboards/hp69/readme.md
reduced the size of the default image
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/hp69/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/hp69/info.json
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* initial commit- copy of default
* beginnings of ergodox layout conversion
* from scratch 2020 RJH ergodox layout!
* remove extra line in keymap
* only shift to layers, led work
* Fleshed out readme
* tweak alt placement
* updated readme
* PR feedback, updated default layer
* Update keyboards/ergodox_infinity/keymaps/rjhilgefort/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Acheron Lasgewloth: layout macro rework
Arrange the layout macro to match the assembled board.
* rename layout macro
The layout supported is equivalent to 60% ANSI with split Backspace and split Right Shift, and supports every extant switch position.
Adds community layout support.
* add LAYOUT_60_ansi support
* add Configurator data
* convert tabs to spaces in lasgweloth.h
The previous implementation generated accents in NFKD -- e.g., i
followed by fn+e would generate í, which is actually an ordinary i
followed by U+0301 COMBINING ACUTE ACCENT. Unfortunately, it turns
out that a bunch of websites and apps (especially European ones
written in languages that use these a lot) were very poorly written,
and will misparse and/or crash if presented with Unicode NFKD. They
require and expect NFKC, with characters like í (U+00ED LATIN SMALL
I WITH ACUTE) that look visually identical -- and are in fact
normalization-equivalent -- but have to be encoded differently.
The new accent implementation handles this in a very flexible way.
Many new comments added as well, as it's also clear that this is going
to need a bit more expansion before it becomes a true polyglot keymap.
Co-authored-by: Yonatan Zunger <zunger@desiderata.lan>
* rework layout macro
Rework the layout macro so it's arranged the way the hardware is.
* info.json: use debug linting
* info.json: rebuild to correct key sequence
* white-space formatting
Makes the keymap and layout macro a bit more representative of where everything is.
* Add Borsdorf
* Delete config.h
* Add basic VIA keymap
* Update default keymap
* Default now uses layout_all
* Default now has layer with reset key
* Fix missing comma in borsdorf keymap
* Update rules.mk to be less specific
* Update chibiOS files
* Update keymaps to swap GUI and Alt keys
* Delete unnecessary readme
* Update VIA keymap to match default
* Remove boilerplate from readme
* Udate Copyright message
* Remove unused key from LAYOUT_rshift
* Update borsdorf.c
Remove unnecessary boiler plate
Co-authored-by: Joel Challis <git@zvecr.com>
* Add copyright message to VIA keymap
Co-authored-by: Joel Challis <git@zvecr.com>
* Fix missing directory in readme
Co-authored-by: Joel Challis <git@zvecr.com>
* Fix incorrect rules.mk
* Update BOOTMAGIC_ENABLE to the preferred lite
Co-authored-by: Joel Challis <git@zvecr.com>
* Remove redundant description from config
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/cutie_club/borsdorf/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/cutie_club/borsdorf/keymaps/via/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initial CK60i support
* Update README, add HAL_PWM and remove AUDIO and BLUETOOTH from rules.mk
* VIA support
* Fix VIA_ENABLE to 'yes'
* Remove CONSOLE_ENABLE from rules.mk
* attribute weak for encoder callback
* Remove KC_NO definition from default keymap
Co-authored-by: Gondolindrim <alvaro.augusto.volpato@gmail.com>
* Update feature_rgblight.md
The note is meant to let people know that this is specific to RGB Backlight and does not work with RGB Matrix based implementations.
* Update docs/feature_rgblight.md
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* chore: pulled the latest from master
Bring my redox layout from my latest redox branch
Bring my latest user stuff from my redox branch
* Update users/danielo515/config.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* chore: some more layouts
* feat: add gaming layer (has a bug)
* chore: more gaming layout
* chore: deactivate gaming layer when switching
* chore: simplify gaming toggle
* Update .vscode/settings.json
Co-authored-by: Drashna Jaelre <drashna@live.com>
* add support for idobao id80 iso layout
* This change is required as there is a logic bug on the board that C7
(capslock) is inverted thus lowercase is with light on. Mind the ! in
the write to the pin.
* Apply suggestions from code review
All fine for me, thanks for the additional information!
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* move device information to separate config.h for id80 iso and ansi
* commit via keymap similar to default. There is a problem with mapping compiling vor via, resulting in KC_ENT residing on KC_PGDN. Switching off via support in rules.mk makes the keyboard behave fine
* change KC_BSLS to KC_NUHS as this is an iso board
Co-authored-by: Carsten <modebm@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
The pcb used for wheatfield/split75 supports ANSI and ISO layout. This
commit adds the ISO variant.
With suggestions from code review:
Co-authored-by: Drashna Jael're <drashna@live.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Create Alter folder
* Revert "Create Alter folder"
This reverts commit 361103b821.
* Added the n40_o folder
* Edited info.json, n40_o.h and rules.mk
* Edited readme as per comment
* Add Herringbone Pro, reorganize herringbone folder
* Finish encoder functionality
* Change image in readme
* Fix info.json
* Flip encoder direction
* Update keyboards/ramonimbao/herringbone/pro/config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/pro/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/pro/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/pro/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Add OLED support, split space, default folder
* Fix LAYOUT_all in info.json
* Remove WPM feature
* Add readme to top level herringbone folder
* Re-add WPM because now the OLED won't turn back on lol
* Add missing timer_read32
* Add OLED wakeup on knob use
* Update keyboards/ramonimbao/herringbone/v1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/v1/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/pro/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/ramonimbao/herringbone/pro/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add small QoL improvments for tapping
* Update keyboards/ramonimbao/herringbone/readme.md
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* Add bootloader instructions and improve LAYOUT_all a bit
* Update keyboards/ramonimbao/herringbone/pro/pro.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/ramonimbao/herringbone/pro/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/ramonimbao/herringbone/pro/info.json
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/ramonimbao/herringbone/pro/keymaps/iso/keymap.c
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/ramonimbao/herringbone/v1/readme.md
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Erovia <Erovia@users.noreply.github.com>
* noop; indent and comment cleanup
* config for rogthefrog layout
* removed encoder function as there is no encoder on this pcb
* removed unnecessary declaration
* replaced individual constants with an enum for extensibility
* removed unused enum
* Added GPL license language
* added copyright for my changes, per GPL
* noop; removed unneeded line continuations; fixed indentation
* Add oddballl v2
- add CPI options
- add scroll support
- add click-and-drag support
- PMW3360 implementation
- ADNS9800 improvements
* Set default make directory
* Update readme with PMW config
* Change bootloader
* Update unused pins on v2
* Remove diode switch
* Move bootloader selection to keyboard version level
* Change default keyboard folder to v1
* Move sensor selection to keymap
* Remove PK debounce
* Change to only send mouse report on change
* Change CPI function cpi type
* Remove EEPROM state check
* Update CPI to only change on key down
* Fix incorrect F8 in keymap
* Add v2.1 with more convenient controller pinout
* Add keyboard readmes
* Update keyboards/oddball/pmw/pmw3360_srom_0x04.h
Remove direct AVR reference
Co-authored-by: Ryan <fauxpark@gmail.com>
* Remove direct AVR reference
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Alexander Tulloh <alex@riberry.io>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initial commit for my Corne keyboard layout.
* Updates to Corne, etc.
Finished working on primary layout for Corne keyboard.
Cleaned up some comments for my 4x12 Ortho layout.
* Changes for crkbd layout
* Fixed the config.h to reflect using ee_hands
* Added RGB configs to crkbd/corne layout
Co-authored-by: Ian Sterling <503326@MC02YT9K9LVCF.tld>
* add support for bigknob
Add support for bigknob macropad
* corrected files
* Apply suggestions from code review
Co-authored-by: Joel Challis <git@zvecr.com>
* corrected tap dance
* Update config.h
* correct image link
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* added GPL headers
* Update readme.md
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* added my keymap
* Tidy up
Add readme, run clang-format, remove some comments
* Fixed some formatting issues
* Update after reading PR checklist
Add GPL header to keymap.c, remove backslash in LAYOUT macro
* Use integer constants for switch labels
* Remove unneeded code, remove F-keys from raise layer
* Use program memory for some text on OLED
* Fixed left over debug code
* tidy up config.h and rules.mk
Remove all unused defines from config.h, and remove options which are the same as the keyboard level make file. Enabled command to be able to toggle NKRO.
* Sagittarius keyboard
* Update Sagittarius keyboard
* fix
* remove info.json as it's very hard to make
* Add license and address PR comments
* Apply suggestions from code review
Co-authored-by: Joel Challis <git@zvecr.com>
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add info json, update keymap
* Fix info json
* Update keymap
* Update keyboards/cannonkeys/sagittarius/info.json
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initial support for Evolv75
* Fix encoder directional and layer support
* Invert knob directions
* Remove info.json and updated README
* Update keyboards/evolv/evolv.c
Update encoder_update call
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/evolv/config.h
Remove description field from USB descriptors
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Remove KC_NO define from default keymap
* Update config.h
New USB descriptor ID numbers
* Update keyboards/evolv/rules.mk
Remove words from bluetooth and audio enable comments
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/evolv/rules.mk
Enable full bootmagic
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add info.json for QMK Configurator
* Edit copyright info, add VIA initial support
* Fix KC_NO seven underscores issue in keymap definitions
* Update info.json
* Update info.json
* ANSI and ISO layouts, info.json file with both
* Reorganized layouts to match info.json order
Co-authored-by: Gondolindrim <alvaro.augusto.volpato@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add proper prototypes for Tap-Hold Per Key functions
* Fix handwired/tennie default keymap
* Remove unneeded references
* Fix tapping term per key check in space cadet
* Pre-emptive fix for tap dance
* Fix marksard/leftover30
* Replace hard coded tapping term with define
* Add GKB-M16 Macro Pad
Add GKB-M16 (gkb_m16) Macro Pad under gkeyboard
* Update keyboards/gkeyboard/gkb_m16/config.h
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/gkeyboard/gkb_m16/keymaps/via/keymap.c
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/gkeyboard/gkb_m16/info.json
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/gkeyboard/gkb_m16/keymaps/default/keymap.c
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Initial commit on new clean branch. Testing out functionality of oled and encoder for default features.
* Cleaned up the initial push and removed the fancy keymap until the extra features and functionality can be tested and made more user friendly.
* Cleaned up the readme some more, compiled and tested both default and via keymaps, and did another round of checks to prepare for starting the PR.
* Cleaning up the keymap to meet expected formatting in a couple places and also adding in the TAP_CODE_DELAY after newly encoutnered encoder issues and inconsistencies.
* Apply suggestions from code review
Co-authored-by: Joel Challis <git@zvecr.com>
* Update keyboards/mechwild/mercutio/readme.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Fixing json syntax.
* Update keyboards/mechwild/mercutio/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Quark PCB for Planck/Preonic
Quark provides alternate bottom row layouts for both the OLKB Planck and Preonic
* Rename rules.mk.txt to rules.mk
* added Tapping Toggle
removed tapping toggle from keymap level
* Update info.json
took out } as requested
* update config.h
added GPL2+ license and #pragma once
* update info.json again
cleaned up syntax
* Apply suggestions from code review
Co-authored-by: Drashna Jaelre <drashna@live.com>
* update config.h
added GPL2+ License
* Update info.json - and again
fixed it - oops
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Add target 'build-for-compare' to `build_keyboard.mk`
The `build-for-compare` target provides an easy way to check the md5 checksum of the generated binary.
You can easily see if there is any change in the generated binaries between the two versions, as in the example below.
```
$ git checkout 0.11.0
M build_keyboard.mk
M tmk_core/rules.mk
Note: checking out '0.11.0'.
HEAD is now at c66df1664 2020 November 28 Breaking Changes Update (#11053)
$ make helix:all:build-for-compare | grep ^MD5
MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a
MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6
MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934
MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791
MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6
MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b
MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d
MD5 (.build/helix_rev2_xulkal.hex) = 01f603dc46bcf9094d7e106831d8f5b1
MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba
$ git checkout 0.11.1
M build_keyboard.mk
M tmk_core/rules.mk
Previous HEAD position was c66df1664 2020 November 28 Breaking Changes Update (#11053)
HEAD is now at cc08e3082 nix-shell: add milc dependency (#11086)
$ make helix:all:build-for-compare | grep ^MD5
MD5 (.build/helix_rev2_default.hex) = 5c3606562c944bb4d18832e601b45d4a
MD5 (.build/helix_rev2_edvorakjp.hex) = 9e43d13d389d518ba7e99cd7337e28d6
MD5 (.build/helix_rev2_five_rows.hex) = 8bcb61c2fd5d237c2997f2fa007d4934
MD5 (.build/helix_rev2_five_rows_jis.hex) = b97cd818d52f73ca2d4e78c86d90a791
MD5 (.build/helix_rev2_froggy.hex) = c492172364188f4e2918b10bf0f3a0a6
MD5 (.build/helix_rev2_froggy_106.hex) = b0861fd735a8f81881a8c02730641a2b
MD5 (.build/helix_rev2_led_test.hex) = 5c97d982a5da5cfb3dacb28a8934b81d
MD5 (.build/helix_rev2_xulkal.hex) = d848383adfd7463b138c6da179cf1436
MD5 (.build/helix_rev2_yshrsmz.hex) = 5a008bca2d0c5790a151c02834c529ba
```
* make builds reproducable by default
* update build_keyboard.mk: remove 'build-for-compare' target
* GNU make (3.81) on macOS 10.14(Mojave) does not have the 'undefine' directive.
* Adopted fauxpark's suggestion.
* Update tmk_core/rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* update tmk_core/rules.mk
* fix tmk_core/rules.mk
Co-authored-by: Zach White <skullydazed@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Adding support for the 2 x 2u layout.
This adds a macro to support the 2 x 2u layout which facilitates
a cleaner looking layout configuration for the people using it.
* Update keyboards/kyria/kyria.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: swampmonster <>
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Added mac variant of portuguese keymap
This keymap is very similar to the existing portuguese keymap, but
some symbols are moved around.
Apply suggestions from code review
Corrected whitespace and implemented some suggested changes.
Co-authored-by: Ryan <fauxpark@gmail.com>
Converted some spaces to nbsp
Added sendstring ISO version
* Apply suggestions from code review
Added suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* Replaced space with nbsp
* Corrected 2 chars in ascii_to_shift_lut
{ and } require shift
Co-authored-by: Ryan <fauxpark@gmail.com>
* My first cut at firmware for te DMQDesign Spin
* Turn off underglow when computer sleeps
* dmqdesigns spin - a little more refined keymap now
* a few more refinements for spin
* missing key up event for CH_CPNL and CH_ASST
* better naming for keymap
* cformat
* Apply suggestions from code review
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Old #include habits die hard... :)
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
To successfully compile bootloadHID, we must have the libusb-config tool, which comes from the libusb-dev package. This package is available in both Ubuntu Groovy and Debian Buster
Co-authored-by: Jonathan Paugh <jpaugh@gmx.com>
* added main keyboard files
* working default and iso maps
* add via config
* made default ansi map
* fixed info.json and made readme
* renamed folders
* reincluding the folders I renamed
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
* I made a change before PR to clean up VIA map that broke it now its fixed
* Apply suggestions from code review
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/boardsource/the_mark/the_mark.h
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Add default mode eighty firmware
* Add via keymap
* Mode80 firmware upgrades
- Removed SPI and PWM drivers from MCU configuration, HAL configuration and Chibi configuration as neither peripherals are being used
- Included second backspace key (row 5, col 14) which should solve the non-appearance of the backspace key on the hotswap PCB
* Add default mode eighty firmware
* Add via keymap
* Update keyboards/mode/eighty/config.h
Remove comment lines from config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update keyboards/mode/eighty/config.h
Remove comments from config.h
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update eighty.c
Add GPLv2 header
* Update eighty.h
Add GPLv2 license header
* Update readme.md
Update README
* Update keyboards/mode/eighty/config.h
Remove keyboard description
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Delete config.h
Delete config.h in keynap folder
* Update keyboards/mode/eighty/rules.mk
Remove feature disabling in rules.mk
Co-authored-by: Ryan <fauxpark@gmail.com>
* Move rules.mk to VIA folder
* Update keyboards/mode/eighty/keymaps/via/rules.mk
Use LTO_ENABLE as short for LINK_TIME_OPTIMIZATION_ENABLE
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Update keyboards/mode/eighty/readme.md
Puts a single image embedded in the readme, and links to the full gallery
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/mode/eighty/readme.md
Use * for markdown list
Co-authored-by: Ryan <fauxpark@gmail.com>
* Apply suggestions from code review
Correct comment characters
Co-authored-by: Ryan <fauxpark@gmail.com>
* Adjusted copyright name, USB descriptor and removed info.json
* Separate Mode80 S and H firwares into subfolders
* Added info.json files for QMK Configurator
* Lowercase folder and filenames
* Remove config definition macros in M80H
* Remove config definition macros in M80S and root
* Change definitions to lowercase parameters
* Moce chconf and mcuconf chibiOS files to root folder
* Move halconf to root folder, keymaps to subfolders
* Update readme for building/flashing guide
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add layers to VIA keymaps, remove CONSOLE_ENABLE
* Push master changes to lib/
* Retrieve lufa and googletest submodules to previous heads at master
* Disabled LTO in VIA keymaps
* Fix layout declaration to lowercase in m80s default keymap
* Added readme's for each M80S and M80H
Co-authored-by: Jaicob <jaicob@icloud.com>
Co-authored-by: Gondolindrim <alvaro.augusto.volpato@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: James Young <18669334+noroadsleft@users.noreply.github.com>
* Create Alter folder
* Revert "Create Alter folder"
This reverts commit 361103b821.
* Add octopad folder
* Added a new keyboard, the Octopad
* Edited files based on requested changes
* Moved encoder code in keyboard level
* Updated the readme
* Corrected the rows and columns of encoders on config.h
* Changed the Vendor ID to D812 since the first one was already taken
* Added support for ast1109MLTRQ speakers
* Increased number of layers to 8 on VIA keymap
* Edited files based on comments
* Edited rules.mk as per comment
* Edited readme.md as per comment
* Update vendor and product info
* Add rev2 for Choco60
* Add keymap for VIA
* Add readme.md for rev1 and rev2
* Use list instead of new line
* Remove DESCRIPTION
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update rev1/readme.md to specify rev1 directly.
Co-authored-by: Ryan <fauxpark@gmail.com>
* Remove some definitions
Co-authored-by: Ryan <fauxpark@gmail.com>
* Remove comments
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* fix abacus so it works with configurator
* create the keymap path if it doesn't exist
* bpiphany/unloved_bastard: remove the nested macros, move default keymap to json
* readd the unloved_bastard default keymap
* fix clueboard/card
* fixup handwired/2x5keypad
* fixup hub16
* matrix/noah: remove the broken matrix print code to fix compilation
* reinstate matrix_print with the right include
* Revert "create the keymap path if it doesn't exist"
This reverts commit af732776a5.
QMK (*Quantum Mechanical Keyboard*) is an open source community centered around developing computer input devices. The community encompasses all sorts of input devices, such as keyboards, mice, and MIDI devices. A core group of collaborators maintains [QMK Firmware](https://github.com/qmk/qmk_firmware), [QMK Configurator](https://config.qmk.fm), [QMK Toolbox](https://github.com/qmk/qmk_toolbox), [qmk.fm](https://qmk.fm), and this documentation with the help of community members like you.
## Get Started
Totally new to QMK? There are two ways to get started:
<divclass="flex-container">
*Basic: [QMK Configurator](https://config.qmk.fm)
* Just select your keyboard from the dropdown and program your keyboard.
* We have an [introductory video](https://www.youtube.com/watch?v=-imgglzDMdY) you can watch.
* There is also an overview [document you can read](newbs_building_firmware_configurator.md).
@@ -28,7 +28,7 @@ As you can see the payload describes all aspects of a keyboard necessary to crea
To compile your keymap into a firmware simply POST your JSON to the `/v1/compile` endpoint. In the following example we've placed the JSON payload into a file named `json_data`.
The QMK API provides an asynchronous API that Web and GUI tools can use to compile arbitrary keymaps for any keyboard supported by [QMK](http://qmk.fm/). The stock keymap template supports all QMK keycodes that do not require supporting C code. Keyboard maintainers can supply their own custom templates to enable more functionality.
The QMK API provides an asynchronous API that Web and GUI tools can use to compile arbitrary keymaps for any keyboard supported by [QMK](https://qmk.fm/). The stock keymap template supports all QMK keycodes that do not require supporting C code. Keyboard maintainers can supply their own custom templates to enable more functionality.
[Clang-format](https://clang.llvm.org/docs/ClangFormat.html) is part of LLVM and can automatically format your code for you, because ain't nobody got time to do it manually. We supply a configuration file for it that applies most of the coding conventions listed above. It will only change whitespace and newlines, so you will still have to remember to include optional braces yourself.
Use the [full LLVM installer](http://llvm.org/builds/) to get clang-format on Windows, or use `sudo apt install clang-format` on Ubuntu.
Use the [full LLVM installer](https://llvm.org/builds/) to get clang-format on Windows, or use `sudo apt install clang-format` on Ubuntu.
If you run it from the command-line, pass `-style=file` as an option and it will automatically find the .clang-format configuration file in the QMK root directory.
@@ -23,7 +23,7 @@ Please keep these things in mind:
# Project Overview
QMK is largely written in C, with specific features and parts written in C++. It targets embedded processors found in keyboards, particularly AVR ([LUFA](http://www.fourwalledcubicle.com/LUFA.php)) and ARM ([ChibiOS](http://www.chibios.com)). If you are already well versed in Arduino programming you'll find a lot of the concepts and limitations familiar. Prior experience with Arduino is not required to successfully contribute to QMK.
QMK is largely written in C, with specific features and parts written in C++. It targets embedded processors found in keyboards, particularly AVR ([LUFA](https://www.fourwalledcubicle.com/LUFA.php)) and ARM ([ChibiOS](https://www.chibios.org)). If you are already well versed in Arduino programming you'll find a lot of the concepts and limitations familiar. Prior experience with Arduino is not required to successfully contribute to QMK.
<!-- FIXME: We should include a list of resources for learning C here. -->
QMK (*Quantum Mechanical Keyboard*) ist eine Open-Source-Community, welche die QMK-Firmware, die QMK-Toolbox, [qmk.fm](https://qmk.fm) und diese Dokumententation betreut. QMK-Firmware ist eine Weiterentwicklung der [tmk\_keyboard](http://github.com/tmk/tmk_keyboard)-Tastatur-Firmware mit vielen nützlichen Zusatzfunktionen für Atmel AVR-Prozessoren. Ursprünglich wurde sie für Produkte von [OLKB](http://olkb.com), das [ErgoDox EZ](http://www.ergodox-ez.com) und das [Clueboard](http://clueboard.co/) entwickelt. Im Laufe der Zeit wurde sie mit Hilfe von [ChibiOS](http://chibios.org) auch für die ARM-Architektur angepasst. Außerdem ist es inzwischen möglich, auch handverdrahtete Tastaturen und selbst geätzte PCBs mit QMK zu verwenden.
QMK (*Quantum Mechanical Keyboard*) ist eine Open-Source-Community, welche die QMK-Firmware, die QMK-Toolbox, [qmk.fm](https://qmk.fm) und diese Dokumententation betreut. QMK-Firmware ist eine Weiterentwicklung der [tmk\_keyboard](https://github.com/tmk/tmk_keyboard)-Tastatur-Firmware mit vielen nützlichen Zusatzfunktionen für Atmel AVR-Prozessoren. Ursprünglich wurde sie für Produkte von [OLKB](https://olkb.com), das [ErgoDox EZ](https://www.ergodox-ez.com) und das [Clueboard](https://clueboard.co/) entwickelt. Im Laufe der Zeit wurde sie mit Hilfe von [ChibiOS](https://chibios.org) auch für die ARM-Architektur angepasst. Außerdem ist es inzwischen möglich, auch handverdrahtete Tastaturen und selbst geätzte PCBs mit QMK zu verwenden.
@@ -18,7 +18,7 @@ Wenn Du es vorziehst mit einer grafischen Oberfläche zu entwickeln kannst Du au
Du wirst ein Programm benötigen, mit dem Du **plain text** (= reiner Text) Dateien bearbeiten und speichern kannst. Wenn Du Windows benutzt, reicht dafür schon das normale `Notepad` und für Linux z.B. `gedit` oder `leafpad`. Beide sind sehr rudimentäre Editoren deren Funktionsumfang aber vollkommen ausreicht. Für macOS' standard `TextEdit` muss man ein bisschen vorsichtig sein und darauf achten, beim Speichern explizit unter _Format_ die Option _Reiner Text_ auszuwählen.
Ansonsten ist es empfehlenswert, einen Editor herunterzuladen der für die Programmierung und das Bearbeiten von Code ausgelegt ist wie z.b [Notepad++](http://notepad-plus-plus.org/), [Sublime Text](https://www.sublimetext.com/) oder [VS Code](https://code.visualstudio.com/).
Ansonsten ist es empfehlenswert, einen Editor herunterzuladen der für die Programmierung und das Bearbeiten von Code ausgelegt ist wie z.b [Notepad++](https://notepad-plus-plus.org/), [Sublime Text](https://www.sublimetext.com/) oder [VS Code](https://code.visualstudio.com/).
?> Immer noch unsicher, welcher Text Editor der Richtige für Dich ist? Laurence Bradford hat eine hervorragende [Einleitung](https://learntocodewith.me/programming/basics/text-editors/) zu dem Thema geschrieben (auf Englisch).
@@ -44,7 +44,7 @@ Wir haben versucht, die Installation der Entwicklungsumgebung für QMK so einfac
Du wirst MSYS2 (o.Ä.) und Git benötigen.
* Befolge die Installationsanleitung auf der [MSYS2 Homepage](http://www.msys2.org)
* Befolge die Installationsanleitung auf der [MSYS2 Homepage](https://www.msys2.org)
* Schließe alle offenen MSYS2 Fenster und öffne ein neues MSYS2 MinGW 64-bit Terminal
* Installiere Git mit dem Kommando: `pacman -S git`
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](http://imgur.com) or another hosting service, please do not include images in your Pull Request.
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](https://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](https://imgur.com) or another hosting service, please do not include images in your Pull Request.
Below the image you should write a short description to help people understand your keymap.
@@ -14,16 +14,11 @@ Some keyboards may have specific instructions for entering the bootloader. For e
To put a device in bootloader mode with USBaspLoader, tap the `RESET` button while holding down the `BOOT` button.
Alternatively, hold `BOOT` while inserting the USB cable.
Zadig will automatically detect the bootloader device. You may sometimes need to check **Options → List All Devices**.
- For keyboards with Atmel AVR MCUs, the bootloader will be named something similar to `ATm32U4DFU`, and have a Vendor ID of `03EB`.
- USBasp bootloaders will appear as `USBasp`, with a VID/PID of `16C0:05DC`.
- AVR keyboards flashed with the QMK-DFU bootloader will be named `<keyboard name> Bootloader` and will also have the VID `03EB`.
- For most ARM keyboards, it will be called `STM32 BOOTLOADER`, and have a VID/PID of `0483:DF11`.
Zadig should automatically detect the bootloader device, but you may sometimes need to check **Options → List All Devices** and select the device from the dropdown instead.
!> If Zadig lists one or more devices with the `HidUsb` driver, your keyboard is probably not in bootloader mode. The arrow will be colored orange and you will be asked to confirm modifying a system driver. **Do not** proceed if this is the case!
If the arrow appears green, select the driver, and click **Install Driver**. The `libusb-win32` driver will usually work for AVR, and `WinUSB` for ARM, but if you still cannot flash the board, try installing a different driver from the list. USBAspLoader devices must use the `libusbK` driver.
If the arrow appears green, select the driver, and click **Install Driver**. See the [list of known bootloaders](#list-of-known-bootloaders) for the correct driver to install.

@@ -43,6 +38,40 @@ Right-click it and hit **Uninstall device**. Make sure to tick **Delete the driv

Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again!
Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again! Otherwise, repeat the process until Zadig reports the correct driver.
?> A full reboot of your computer may sometimes be necessary at this point, to get Windows to pick up the new driver.
## List of Known Bootloaders
This is a list of known bootloader devices and their USB vendor and product IDs, as well as the correct driver to assign for flashing with QMK. Note that the usbser and HidUsb drivers are built in to Windows, and cannot be assigned with Zadig - if your device has an incorrect driver, you must use the Device Manager to uninstall it as described in the previous section.
The device name here is the name that appears in Zadig, and may not be what the Device Manager or QMK Toolbox displays.
QMK (*Quantum Mechanical Keyboard*) es una comunidad open source que mantiene el firmware QMK, QMK Toolbox, qmk.fm, y estos documentos. El firmware QMK es un firmware para teclados basado en [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) con algunas características útiles para controladores Atmel AVR, y más específicamente, la [línea de productos OLKB](http://olkb.com), el teclado [ErgoDox EZ](http://www.ergodox-ez.com), y la [línea de productos Clueboard](http://clueboard.co/). También ha sido portado a chips ARM chips usando ChibiOS. Lo puedes utilizar para manejar tu propio teclado ya sea cableado a mano o basado en una PCB personalizada.
QMK (*Quantum Mechanical Keyboard*) es una comunidad open source que mantiene el firmware QMK, QMK Toolbox, qmk.fm, y estos documentos. El firmware QMK es un firmware para teclados basado en [tmk\_keyboard](https://github.com/tmk/tmk_keyboard) con algunas características útiles para controladores Atmel AVR, y más específicamente, la [línea de productos OLKB](https://olkb.com), el teclado [ErgoDox EZ](https://www.ergodox-ez.com), y la [línea de productos Clueboard](https://clueboard.co/). También ha sido portado a chips ARM chips usando ChibiOS. Lo puedes utilizar para manejar tu propio teclado ya sea cableado a mano o basado en una PCB personalizada.
## Cómo conseguirlo
@@ -29,4 +29,4 @@ Este ejemplo compilaría la revisión `rev4` del teclado `planck` con el keymap
## Cómo personalizar
QMK tiene montones de [características](es/features.md) para explorar, y una buena cantidad de [documentación de referencia](http://docs.qmk.fm) en la que sumergirse. Se pueden sacar provecho de la mayoría de las características modificando tu [keymap](es/keymap.md), y cambiando los [keycodes](es/keycodes.md).
QMK tiene montones de [características](es/features.md) para explorar, y una buena cantidad de [documentación de referencia](https://docs.qmk.fm) en la que sumergirse. Se pueden sacar provecho de la mayoría de las características modificando tu [keymap](es/keymap.md), y cambiando los [keycodes](es/keycodes.md).
QMK es compatible con una variedad de hardware. Si tu procesador puede ser dirigido por [LUFA](http://www.fourwalledcubicle.com/LUFA.php) o [ChibiOS](http://www.chibios.com), probablemente puedes hacer que QMK se ejecute en él. Esta sección explora cómo hacer que QMK se ejecute y se comunique con hardware de todo tipo.
QMK es compatible con una variedad de hardware. Si tu procesador puede ser dirigido por [LUFA](https://www.fourwalledcubicle.com/LUFA.php) o [ChibiOS](https://www.chibios.org), probablemente puedes hacer que QMK se ejecute en él. Esta sección explora cómo hacer que QMK se ejecute y se comunique con hardware de todo tipo.
* [Pautas de teclados](hardware_keyboard_guidelines.md)
@@ -32,7 +32,7 @@ Esto creará todos los archivos necesarios para tu nuevo teclado, y rellenará l
## `readme.md`
Aquí es donde describirás tu teclado. Por favor sigue la [Plantilla del readme de teclados](documentation_templates.md#keyboard-readmemd-template) al escribir tu `readme.md`. Te animamos a colocar una imagen en la parte superior de tu `readme.md`. Por favor, utiliza un servicio externo como [Imgur](http://imgur.com) para alojar las imágenes.
Aquí es donde describirás tu teclado. Por favor sigue la [Plantilla del readme de teclados](documentation_templates.md#keyboard-readmemd-template) al escribir tu `readme.md`. Te animamos a colocar una imagen en la parte superior de tu `readme.md`. Por favor, utiliza un servicio externo como [Imgur](https://imgur.com) para alojar las imágenes.
@@ -98,7 +98,7 @@ Por ejemplo, si tienes un PCB de 60% que soporta ANSI e ISO podría definir los
En un esfuerzo por mantener el tamaño de repo abajo ya no estamos aceptando archivos binarios de cualquier formato, con pocas excepciones. Alojarlos en otro lugar (por ejemplo <https://imgur.com>) y enlazarlos en el `readme.md` es preferible.
Para archivos de hardware (tales como placas, casos, pcb) puedes contribuir a [qmk.fm repo](https://github.com/qmk/qmk.fm) y estarán disponibles en [qmk.fm](http://qmk.fm). Archivos descargables se almacenan en `/<teclado>/` (nombre sigue el mismo formato que el anterior), se sirven en `http://qmk.fm/<teclado>/`, y se generan páginas de `/_pages/<teclado>/` que se sirven en la misma ubicación (Los archivos .md se generan en archivos .html mediante Jekyll). Echa un vistazo a la carpeta `lets_split` para ver un ejemplo.
Para archivos de hardware (tales como placas, casos, pcb) puedes contribuir a [qmk.fm repo](https://github.com/qmk/qmk.fm) y estarán disponibles en [qmk.fm](https://qmk.fm). Archivos descargables se almacenan en `/<teclado>/` (nombre sigue el mismo formato que el anterior), se sirven en `https://qmk.fm/<teclado>/`, y se generan páginas de `/_pages/<teclado>/` que se sirven en la misma ubicación (Los archivos .md se generan en archivos .html mediante Jekyll). Echa un vistazo a la carpeta `lets_split` para ver un ejemplo.
## Predeterminados de teclado
@@ -140,7 +140,7 @@ El año debe ser el primer año en que se crea el archivo. Si el trabajo se hizo
## Licencia
El núcleo de QMC está licenciado bajo la [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). Si estás enviando binarios para los procesadores AVR puedes elegir cualquiera [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) o [GPLv3](https://www.gnu.org/licenses/gpl.html). Si estás enviando binarios para ARM procesadores debes elegir [GPL Versión 3](https://www.gnu.org/licenses/gpl.html) para cumplir con los [ChibiOS](http://www.chibios.org) licencia GPLv3.
El núcleo de QMC está licenciado bajo la [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). Si estás enviando binarios para los procesadores AVR puedes elegir cualquiera [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) o [GPLv3](https://www.gnu.org/licenses/gpl.html). Si estás enviando binarios para ARM procesadores debes elegir [GPL Versión 3](https://www.gnu.org/licenses/gpl.html) para cumplir con los [ChibiOS](https://www.chibios.org) licencia GPLv3.
Si tu teclado hace uso de la [uGFX](https://gfx.io) características dentro de QMK debes cumplir con la [Licencia de uGFX](https://ugfx.io/license.html), que requiere una licencia comercial separada antes de vender un dispositivo que contiene uGFX.
QMK es un poderoso firmware Open Source para tu teclado mecánico. Puedes utilizar QMK para personalizar tu teclado en maneras a la vez simples y potentes. Gente de todos los niveles de habilidad, desde completos novatos hasta expertos programadores, han utilizado con éxito QMK para personalizar sus teclados. Esta guía te ayudará a hacer lo mismo, sin importar tu nivel de habilidad.
¿No estás seguro de si tu teclado puede ejecutar QMK? Si es un teclado mecánico construido por ti mismo probablemente puedas. Damos soporte a [gran número de placas de hobbistas](http://qmk.fm/keyboards/), e incluso si tu teclado actual no pudiera ejecutar QMK no deberías tener problemas encontrando uno que cumpliera tus necesidades.
¿No estás seguro de si tu teclado puede ejecutar QMK? Si es un teclado mecánico construido por ti mismo probablemente puedas. Damos soporte a [gran número de placas de hobbistas](https://qmk.fm/keyboards/), e incluso si tu teclado actual no pudiera ejecutar QMK no deberías tener problemas encontrando uno que cumpliera tus necesidades.
Note that running `make` with `sudo` is generally ***not*** a good idea, and you should use one of the former methods, if possible.
### Linux `udev` Rules
### Linux `udev` Rules :id=linux-udev-rules
On Linux, you'll need proper privileges to communicate with the bootloader device. You can either use `sudo` when flashing firmware (not recommended), or place [this file](https://github.com/qmk/qmk_firmware/tree/master/util/udev/50-qmk.rules) into `/etc/udev/rules.d/`.
This page details various common questions people have about troubleshooting their keyboards.
# Debug Console
## Debugging :id=debugging
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DEBUG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
```c
voidkeyboard_post_init_user(void){
// Customise these values to desired behaviour
debug_enable=true;
debug_matrix=true;
//debug_keyboard=true;
//debug_mouse=true;
}
```
## Debugging Tools
There are two different tools you can use to debug your keyboard.
### Debugging With QMK Toolbox
For compatible platforms, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) can be used to display debug messages from your keyboard.
### Debugging With hid_listen
Prefer a terminal based solution? [hid_listen](https://www.pjrc.com/teensy/hid_listen.html), provided by PJRC, can also be used to display debug messages. Prebuilt binaries for Windows,Linux,and MacOS are available.
## Sending Your Own Debug Messages
Sometimes it's useful to print debug messages from within your [custom code](custom_quantum_functions.md). Doing so is pretty simple. Start by including `print.h` at the top of your file:
```c
#include"print.h"
```
After that you can use a few different print functions:
*`print("string")`: Print a simple string.
*`uprintf("%s string", var)`: Print a formatted string
*`dprint("string")` Print a simple string, but only when debug mode is enabled
*`dprintf("%s string", var)`: Print a formatted string, but only when debug mode is enabled
## Debug Examples
Below is a collection of real world debugging examples. For additional information, refer to [Debugging/Troubleshooting QMK](faq_debug.md).
### Which matrix position is this keypress?
When porting, or when attempting to diagnose pcb issues, it can be useful to know if a keypress is scanned correctly. To enable logging for this scenario, add the following code to your keymaps `keymap.c`
When testing performance issues, it can be useful to know the frequency at which the switch matrix is being scanned. To enable logging for this scenario, add the following code to your keymaps `config.h`
```c
#define DEBUG_MATRIX_SCAN_RATE
```
Example output
```text
> matrix scan frequency: 315
> matrix scan frequency: 313
> matrix scan frequency: 316
> matrix scan frequency: 316
> matrix scan frequency: 316
> matrix scan frequency: 316
```
## `hid_listen` Can't Recognize Device
When debug console of your device is not ready you will see like this:
@@ -11,7 +98,7 @@ When debug console of your device is not ready you will see like this:
Waiting for device:.........
```
once the device is plugged in then *hid_listen* finds it you will get this message:
Once the device is plugged in then *hid_listen* finds it you will get this message:
```
Waiting for new device:.........................
@@ -20,129 +107,12 @@ Listening:
If you can't get this 'Listening:' message try building with `CONSOLE_ENABLE=yes` in [Makefile]
You may need privilege to access the device on OS like Linux.
- try `sudo hid_listen`
You may need privileges to access the device an OS like Linux. Try `sudo hid_listen`.
## Can't Get Message on Console
Check:
- *hid_listen* finds your device. See above.
- Enable debug with pressing **Magic**+d. See [Magic Commands](https://github.com/tmk/tmk_keyboard#magic-commands).
-set `debug_enable=true`. See [Testing and Debugging](newbs_testing_debugging.md#debugging)
-try using 'print' function instead of debug print. See **common/print.h**.
-disconnect other devices with console function. See [Issue #97](https://github.com/tmk/tmk_keyboard/issues/97).
***
# Miscellaneous
## Safety Considerations
You probably don't want to "brick" your keyboard, making it impossible
to rewrite firmware onto it. Here are some of the parameters to show
what things are (and likely aren't) too risky.
- If your keyboard map does not include RESET, then, to get into DFU
mode, you will need to press the reset button on the PCB, which
requires unscrewing the bottom.
- Messing with tmk_core / common files might make the keyboard
inoperable
- Too large a .hex file is trouble; `make dfu` will erase the block,
test the size (oops, wrong order!), which errors out, failing to
flash the keyboard, leaving it in DFU mode.
- To this end, note that the maximum .hex file size on Planck is
7000h (28672 decimal)
```
Linking: .build/planck_rev4_cbbrowne.elf [OK]
Creating load file for Flash: .build/planck_rev4_cbbrowne.hex [OK]
Size after:
text data bss dec hex filename
0 22396 0 22396 577c planck_rev4_cbbrowne.hex
```
- The above file is of size 22396/577ch, which is less than
28672/7000h
- As long as you have a suitable alternative .hex file around, you
can retry, loading that one
- Some of the options you might specify in your keyboard's Makefile
consume extra memory; watch out for BOOTMAGIC_ENABLE,
- DFU tools do /not/ allow you to write into the bootloader (unless
you throw in extra fruit salad of options), so there is little risk
there.
- EEPROM has around a 100000 write cycle. You shouldn't rewrite the
firmware repeatedly and continually; that'll burn the EEPROM
eventually.
## NKRO Doesn't work
First you have to compile firmware with this build option `NKRO_ENABLE` in **Makefile**.
Try `Magic`**N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work you need to switch to **6KRO** mode, in particular when you are in BIOS.
If your firmware built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic`**N** command(`Space+N` by default). This setting is stored in EEPROM and kept over power cycles.
Use `1UL<<16` instead of `1<<16` in `read_cols()` in [matrix.h] when your columns goes beyond 16.
In C `1` means one of [int] type which is [16 bit] in case of AVR so you can't shift left more than 15. You will get unexpected zero when you say `1<<16`. You have to use [unsigned long] type with `1UL`.
## Special Extra Key Doesn't Work (System, Audio Control Keys)
You need to define `EXTRAKEY_ENABLE` in `rules.mk` to use them in QMK.
```
EXTRAKEY_ENABLE = yes # Audio control and System control
```
## Wakeup from Sleep Doesn't Work
In Windows check `Allow this device to wake the computer` setting in Power **Management property** tab of **Device Manager**. Also check BIOS setting.
Pressing any key during sleep should wake host.
## Using Arduino?
**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
Arduino Leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
## Enabling JTAG
By default, the JTAG debugging interface is disabled as soon as the keyboard starts up. JTAG-capable MCUs come from the factory with the `JTAGEN` fuse set, and it takes over certain pins of the MCU that the board may be using for the switch matrix, LEDs, etc.
If you would like to keep JTAG enabled, just add the following to your `config.h`:
```c
#define NO_JTAG_DISABLE
```
## USB 3 Compatibility
I heard some people have a problem with USB 3 port, try USB 2 port.
## Problem on BIOS (UEFI)/Resume (Sleep & Wake)/Power Cycles
Some people reported their keyboard stops working on BIOS and/or after resume(power cycles).
As of now root of its cause is not clear but some build options seem to be related. In Makefile try to disable those options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
@@ -11,7 +11,7 @@ Keycodes are actually defined in [common/keycode.h](https://github.com/qmk/qmk_f
There are 3 standard keyboard layouts in use around the world- ANSI, ISO, and JIS. North America primarily uses ANSI, Europe and Africa primarily use ISO, and Japan uses JIS. Regions not mentioned typically use either ANSI or ISO. The keycodes corresponding to these layouts are shown here:
<!-- Source for this image: http://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
<!-- Source for this image: https://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
## How Can I Make Custom Names For Complex Keycodes?
@@ -42,8 +42,8 @@ The key found on most modern keyboards that is located between `KC_RGUI` and `KC
Use keycode for Print Screen(`KC_PSCREEN` or `KC_PSCR`) instead of `KC_SYSREQ`. Key combination of 'Alt + Print Screen' is recognized as 'System request'.
See [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) and
* http://en.wikipedia.org/wiki/Magic_SysRq_key
* http://en.wikipedia.org/wiki/System_request
* https://en.wikipedia.org/wiki/Magic_SysRq_key
* https://en.wikipedia.org/wiki/System_request
## Power Keys Aren't Working
@@ -60,13 +60,13 @@ Modifier keys or layers can be stuck unless layer switching is configured proper
For Modifier keys and layer actions you have to place `KC_TRANS` on same position of destination layer to unregister the modifier key or return to previous layer on release event.
This feature is for *mechanical lock switch* like [this Alps one](http://deskthority.net/wiki/Alps_SKCL_Lock). You can enable it by adding this to your `config.h`:
This feature is for *mechanical lock switch* like [this Alps one](https://deskthority.net/wiki/Alps_SKCL_Lock). You can enable it by adding this to your `config.h`:
Testing your keyboard is usually pretty straightforward. Press every single key and make sure it sends the keys you expect. You can use [QMK Configurator](https://config.qmk.fm/#/test/)'s test mode to check your keyboard, even if it doesn't run QMK.
## Safety Considerations
You probably don't want to "brick" your keyboard, making it impossible
to rewrite firmware onto it. Here are some of the parameters to show
what things are (and likely aren't) too risky.
- If your keyboard map does not include RESET, then, to get into DFU
mode, you will need to press the reset button on the PCB, which
requires unscrewing the bottom.
- Messing with tmk_core / common files might make the keyboard
inoperable
- Too large a .hex file is trouble; `make dfu` will erase the block,
test the size (oops, wrong order!), which errors out, failing to
flash the keyboard, leaving it in DFU mode.
- To this end, note that the maximum .hex file size on e.g. Planck
is 7000h (28672 decimal)
```
Linking: .build/planck_rev4_cbbrowne.elf [OK]
Creating load file for Flash: .build/planck_rev4_cbbrowne.hex [OK]
Size after:
text data bss dec hex filename
0 22396 0 22396 577c planck_rev4_cbbrowne.hex
```
- The above file is of size 22396/577ch, which is less than
28672/7000h
- As long as you have a suitable alternative .hex file around, you
can retry, loading that one
- Some of the options you might specify in your keyboard's Makefile
consume extra memory; watch out for BOOTMAGIC_ENABLE,
- DFU tools do /not/ allow you to write into the bootloader (unless
you throw in an extra fruit salad of options), so there is little risk
there.
- EEPROM has around a 100000 (100k) write cycle. You shouldn't rewrite
the firmware repeatedly and continually; that'll burn the EEPROM
eventually.
## NKRO Doesn't work
First you have to compile firmware with the build option `NKRO_ENABLE` in **Makefile**.
Try `Magic`**N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work and you will need to switch to **6KRO** mode, in particular when you are in BIOS.
If your firmware was built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic`**N** command(`Space+N` by default). This setting is stored in EEPROM and kept over power cycles.
Use `1UL<<16` instead of `1<<16` in `read_cols()` in [matrix.h] when your columns goes beyond 16.
In C `1` means one of [int] type which is [16 bit] in case of AVR, so you can't shift left more than 15. Thus, calculating `1<<16` will unexpectedly equal zero. To work around this, you have to use [unsigned long] type with `1UL`.
## Special Extra Key Doesn't Work (System, Audio Control Keys)
You need to define `EXTRAKEY_ENABLE` in `rules.mk` to use them in QMK.
```
EXTRAKEY_ENABLE = yes # Audio control and System control
```
## Wake from Sleep Doesn't Work
In Windows check `Allow this device to wake the computer` setting in **Power Management** property tab of **Device Manager**. Also check your BIOS settings. Pressing any key during sleep should wake host.
## Using Arduino?
**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
Arduino Leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
## Enabling JTAG
By default, the JTAG debugging interface is disabled as soon as the keyboard starts up. JTAG-capable MCUs come from the factory with the `JTAGEN` fuse set, and it takes over certain pins of the MCU that the board may be using for the switch matrix, LEDs, etc.
If you would like to keep JTAG enabled, just add the following to your `config.h`:
```c
#define NO_JTAG_DISABLE
```
## USB 3 Compatibility
Some problems can be fixed by switching from a USB 3.x port to a USB 2.0 port.
## Mac Compatibility
### OS X 10.11 and Hub
See here: https://geekhack.org/index.php?topic=14290.msg1884034#msg1884034
## Problem in BIOS (UEFI) Setup/Resume (Sleep & Wake)/Power Cycles
Some people reported their keyboard stops working in BIOS and/or after resume(power cycles).
As of now the root cause is not clear, but some build options seem to be related. In Makefile, try to disable options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
@@ -56,7 +56,7 @@ Define these arrays listing all the LEDs in your `<keyboard>.c`:
....
}
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://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` ).
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` ).
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 function](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 functions](ref_functions.md) for additional functionality. For example `reset_keyboard()` allows you to reset the keyboard as part of a macro.
@@ -27,6 +27,10 @@ Once you have made the necessary changes to the mouse report, you need to send i
When the mouse report is sent, the x, y, v, and h values are set to 0 (this is done in `pointing_device_send()`, which can be overridden to avoid this behavior). This way, button states persist, but movement will only occur once. For further customization, both `pointing_device_init` and `pointing_device_task` can be overridden.
Additionally, by default, `pointing_device_send()` will only send a report when the report has actually changed. This prevents it from continuously sending mouse reports, which will keep the host system awake. This behavior can be changed by creating your own `pointing_device_send()` function.
Also, you use the `has_mouse_report_changed(new, old)` function to check to see if the report has changed.
In the following example, a custom key is used to click the mouse and scroll 127 units vertically and horizontally, then undo all of that when released - because that's a totally useful function. Listen, this is an example:
Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf) and the header file `drivers/issi/is31fl3731.h`. The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now).
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.h`. The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now).
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0` right now).
Where `X_Y` is the location of the LED in the matrix defined by [the datasheet](https://www.issi.com/WW/pdf/31FL3733.pdf) and the header file `drivers/issi/is31fl3733.h`. The `driver` is the index of the driver you defined in your `config.h` (Only `0` right now).
---
@@ -296,6 +296,19 @@ You can disable a single effect by defining `DISABLE_[EFFECT_NAME]` in your `con
?> **Note:** Lighting Layers is an RGB Light feature, it will not work for RGB Matrix. See [RGB Matrix Indicators](feature_rgb_matrix.md?indicators) for details on how to do so.
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.
@@ -194,7 +196,7 @@ it easy to use your underglow LEDs as status indicators to show which keyboard l
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:
To define a layer, we modify `keymap.c` to list the 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:
```c
// Light LEDs 6 to 9 and 12 to 15 red when caps lock is active. Hard to ignore!
Steve Losh described the [Space Cadet Shift](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) quite well. Essentially, when you tap Left Shift on its own, you get an opening parenthesis; tap Right Shift on its own and you get the closing one. When held, the Shift keys function as normal. Yes, it's as cool as it sounds, and now even cooler supporting Control and Alt as well!
Steve Losh described the [Space Cadet Shift](https://stevelosh.com/blog/2012/10/a-modern-space-cadet/) quite well. Essentially, when you tap Left Shift on its own, you get an opening parenthesis; tap Right Shift on its own and you get the closing one. When held, the Shift keys function as normal. Yes, it's as cool as it sounds, and now even cooler supporting Control and Alt as well!
[Stenography](https://en.wikipedia.org/wiki/Stenotype) is a method of writing most often used by court reports, closed-captioning, and real-time transcription for the deaf. In stenography words are chorded syllable by syllable with a mixture of spelling, phonetic, and shortcut (briefs) strokes. Professional stenographers can reach 200-300 WPM without any of the strain usually found in standard typing and with far fewer errors (>99.9% accuracy).
The [Open Steno Project](http://www.openstenoproject.org/) has built an open-source program called Plover that provides real-time translation of steno strokes into words and commands. It has an established dictionary and supports
The [Open Steno Project](https://www.openstenoproject.org/) has built an open-source program called Plover that provides real-time translation of steno strokes into words and commands. It has an established dictionary and supports
## Plover with QWERTY Keyboard :id=plover-with-qwerty-keyboard
@@ -52,7 +52,6 @@ On the display tab click 'Open stroke display'. With Plover disabled you should
# Flashing Instructions and Bootloader Information
There are quite a few different types of bootloaders that keyboards use, and just about all of them use a different flashing method. Luckily, projects like the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) aim to be compatible with all the different types without having to think about it much, but this article will describe the different types of bootloaders, and available methods for flashing them.
There are quite a few different types of bootloaders that keyboards use, and almost all of them use their own flashing method and tools. Luckily, projects like the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) aim to support as many of them as possible, but this article will describe the different types of bootloaders, and available methods for flashing them.
If you have a bootloader selected with the `BOOTLOADER` variable in your `rules.mk`, QMK will automatically calculate if your .hex file is the right size to be flashed to the device, and output the total size in bytes (along with the max).
For AVR-based keyboards, QMK will automatically calculate if your `.hex` file is the right size to be flashed to the device based on the `BOOTLOADER` value set in `rules.mk`, and output the total size in bytes (along with the max).
## DFU
You will also be able to use the CLI to flash your keyboard, by running:
```
$ qmk flash -kb <keyboard> -km <keymap>
```
See the [`qmk flash`](cli_commands.md#qmk-flash) documentation for more information.
Atmel's DFU bootloader comes on all atmega32u4 chips by default, and is used by many keyboards that have their own ICs on their PCBs (Older OLKB boards, Clueboards). Some keyboards may also use LUFA's DFU bootloader (or QMK's fork) (Newer OLKB boards) that adds in additional features specific to that hardware.
## Atmel DFU
To ensure compatibility with the DFU bootloader, make sure this block is present your `rules.mk` (optionally with `lufa-dfu` or `qmk-dfu` instead):
Atmel's DFU bootloader comes on all USB AVRs by default (except for 16/32U4RC), and is used by many keyboards that have their own ICs on their PCBs (older OLKB boards, Clueboards). Some keyboards may also use LUFA's DFU bootloader, or QMK's fork of it (newer OLKB boards), that adds in additional features specific to that hardware.
To ensure compatibility with the DFU bootloader, make sure this block is present in your `rules.mk` (optionally with `lufa-dfu` or `qmk-dfu` instead):
* [dfu-programmer](https://github.com/dfu-programmer/dfu-programmer) / `:dfu` in QMK (recommended command line)
* [dfu-programmer](https://github.com/dfu-programmer/dfu-programmer) / `:dfu` target in QMK (recommended command line)
Flashing sequence:
1.Press the `RESET` keycode, or tap the RESET button (or short RST to GND).
1.Enter the bootloader using any of the following methods:
* Press the `RESET` keycode
* Press the `RESET` button on the PCB if available
* Short RST to GND quickly
2. Wait for the OS to detect the device
3. Erase the memory (may be done automatically)
3. Erase the flash memory (will be done automatically if using the Toolbox or CLI/`make` command)
4. Flash a .hex file
5. Reset the device into application mode (may be done automatically)
or:
make <keyboard>:<keymap>:dfu
5. Reset the device into application mode (will be done automatically as above)
### QMK DFU
QMK has a fork of the LUFA DFU bootloader that allows for a simple matrix scan for exiting the bootloader and returning to the application, as well as flashing an LED/making a ticking noise with a speaker when things are happening. To enable these features, use this block in your `config.h` (The key that exits the bootloader needs to be hooked-up to the INPUT and OUTPUT defined here):
QMK maintains [a fork of the LUFA DFU bootloader](https://github.com/qmk/lufa/tree/master/Bootloaders/DFU) that additionally performs a simple matrix scan for exiting the bootloader and returning to the application, as well as flashing an LED/making a ticking noise with a speaker when things are happening. To enable these features, add the following defines to your `config.h`:
#define QMK_ESC_OUTPUT F1 // usually COL
#define QMK_ESC_INPUT D5 // usually ROW
#define QMK_LED E6
#define QMK_SPEAKER C6
```c
#define QMK_ESC_OUTPUT F1 // COL pin if COL2ROW
#define QMK_ESC_INPUT D5 // ROW pin if COL2ROW
// Optional:
//#define QMK_LED E6
//#define QMK_SPEAKER C6
```
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](feature_bootmagic.md#bootmagic-lite), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
The Manufacturer and Product names are automatically pulled from your `config.h`, and "Bootloader" is added to the product.
The manufacturer and product strings are automatically pulled from `config.h`, with "Bootloader" appended to the product string.
To generate this bootloader, use the `bootloader` target, eg `make planck/rev4:default:bootloader`.
To generate this bootloader, use the `bootloader` target, eg.`make planck/rev4:default:bootloader`. To generate a production-ready .hex file (combining QMK and the bootloader), use the `production` target, eg. `make planck/rev4:default:production`.
To generate a production-ready .hex file (containing the application and the bootloader), use the `production` target, eg `make planck/rev4:default:production`.
### `make` Targets
### DFU commands
There are a number of DFU commands that you can use to flash firmware to a DFU device:
*`:dfu` - This is the normal option and waits until a DFU device is available, and then flashes the firmware. This will check every 5 seconds, to see if a DFU device has appeared.
*`:dfu-ee` - This flashes an `eep` file instead of the normal hex. This is uncommon.
*`:dfu-split-left` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
*`:dfu-split-right` - This flashes the normal firmware, just like the default option (`:dfu`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Elite C based split keyboards._
*`:dfu`: Checks every 5 seconds until a DFU device is available, and then flashes the firmware.
*`:dfu-split-left` and `:dfu-split-right`: Flashes the firmware as with `:dfu`, but also sets the handedness setting in EEPROM. This is ideal for Elite-C-based split keyboards.
## Caterina
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (any keyboard built with a Pro Micro, or clone), and uses the avr109 protocol to communicate through virtual serial. Bootloaders like [A-Star](https://www.pololu.com/docs/0J61/9) are based on Caterina.
Arduino boards and their clones use the [Caterina bootloader](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) or a variant of it (any keyboard built with a Pro Micro or clone, and the Pololu A-Star), and uses the AVR109 protocol to communicate through virtual serial.
To ensure compatibility with the Caterina bootloader, make sure this block is present your `rules.mk`:
To ensure compatibility with the Caterina bootloader, make sure this block is present in your `rules.mk`:
1.Press the `RESET` keycode, or short RST to GND quickly (you only have 7 seconds to flash once it enters)
1.Enter the bootloader using any of the following methods (you only have 7 seconds to flash once it enters; some variants may require you to reset twice within 750 milliseconds):
* Press the `RESET` keycode
* Press the `RESET` button on the PCB if available
* Short RST to GND quickly
2. Wait for the OS to detect the device
3. Flash a .hex file
4. Wait for the device to reset automatically
or
### `make` Targets
make <keyboard>:<keymap>:avrdude
*`:avrdude`: Checks every 5 seconds until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
*`:avrdude-loop`: Flashes the firmware as with `:avrdude`, but after each device is flashed, will attempt to flash again. This is useful for bulk flashing. Hit Ctrl+C to escape the loop.
*`:avrdude-split-left` and `:avrdude-split-right`: Flashes the firmware as with `:avrdude`, but also sets the handedness setting in EEPROM. This is ideal for Pro Micro-based split keyboards.
## HalfKay
### Caterina commands
HalfKay is a super-slim bootloader developed by PJRC that presents itself as an HID device (which requires no additional driver), and comes preflashed on all Teensys, namely the 2.0. It is currently closed-source, and thus once overwritten (eg. via ISP flashing another bootloader), cannot be restored.
There are a number of DFU commands that you can use to flash firmware to a DFU device:
*`:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
*`:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again. This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Ctrl+C._
*`:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
*`:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
## Halfkay
Halfkay is a super-slim protocol developed by PJRC that uses HID, and comes on all Teensys (namely the 2.0).
To ensure compatibility with the Halfkay bootloader, make sure this block is present your `rules.mk`:
To ensure compatibility with the Halfkay bootloader, make sure this block is present in your `rules.mk`:
1.Press the `RESET` keycode, or short RST to GND quickly (you only have 7 seconds to flash once it enters)
1.Enter the bootloader using any of the following methods (you only have 7 seconds to flash once it enters):
* Press the `RESET` keycode
* Press the `RESET` button on the Teensy or PCB if available
* short RST to GND quickly
2. Wait for the OS to detect the device
3. Flash a .hex file
4. Reset the device into application mode (may be done automatically)
## USBasploader
USBasploader is a bootloader developed by matrixstorm. It is used in some non-USB AVR chips such as the ATmega328P, which run V-USB.
USBasploader is a bootloader originally by [Objective Development](https://www.obdev.at/products/vusb/usbasploader.html). It emulates a USBasp ISP programmer and is used in some non-USB AVR chips such as the ATmega328P, which run V-USB.
To ensure compatibility with the USBasploader bootloader, make sure this block is present in your `rules.mk`:
1.Press the `RESET` keycode, or keep the boot pin shorted to GND while quickly shorting RST to GND
1.Enter the bootloader using any of the following methods:
* Press the `RESET` keycode
* Keep the `BOOT` button held while quickly tapping the `RESET` button on the PCB
2. Wait for the OS to detect the device
3. Flash a .hex file
4.Reset the device into application mode (may be done automatically)
4.Press the `RESET` button on the PCB or short RST to GND
## BootloadHID
BootloadHID is a USB bootloader for AVR microcontrollers. The uploader tool requires no kernel level driver on Windows and can therefore be run without installing any DLLs.
BootloadHID is a USB bootloader for AVR microcontrollers. It presents itself as an HID input device, much like HalfKay, and can therefore be run without installing any driver on Windows.
To ensure compatibility with the bootloadHID bootloader, make sure this block is present your `rules.mk`:
To ensure compatibility with the bootloadHID bootloader, make sure this block is present in your `rules.mk`:
```make
# Bootloader selection
# Teensy halfkay
# Pro Micro caterina
# Atmel DFU atmel-dfu
# LUFA DFU lufa-dfu
# QMK DFU qmk-dfu
# ATmega32A bootloadHID
# ATmega328P USBasp
BOOTLOADER= bootloadHID
```
Compatible flashers:
* [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash) (recommended Windows GUI)
1. Enter the bootloader using any of the following methods:
* Tap the `RESET` keycode (may not work on all devices)
* Hold the salt key while plugging the keyboard in (usually documented within keyboard readme)
* Tap the `RESET` keycode
* Hold the salt key while plugging the keyboard in - for PS2AVRGB boards, this is usually the key connected to MCU pins A0 and B0, otherwise it will be documented in your keyboard's readme
2. Wait for the OS to detect the device
3. Flash a .hex file
4. Reset the device into application mode (may be done automatically)
or:
## STM32/APM32 DFU
make <keyboard>:<keymap>:bootloadHID
All STM32 and APM32 MCUs, except for F103 (see the [STM32duino section](#stm32duino)) come preloaded with a factory bootloader that cannot be modified nor deleted.
## STM32
To ensure compatibility with the STM32-DFU bootloader, make sure this block is present in your `rules.mk` (optionally with `apm32-dfu` instead):
All STM32 chips come preloaded with a factory bootloader that cannot be modified nor deleted. Some STM32 chips have bootloaders that do not come with USB programming (e.g. STM32F103) but the process is still the same.
At the moment, no `BOOTLOADER`variable is needed on `rules.mk` for STM32.
* [dfu-util](https://dfu-util.sourceforge.net/) / `:dfu-util` target in QMK (recommended command line)
Flashing sequence:
1. Enter the bootloader using any of the following methods:
* Tap the `RESET` keycode (may not work on STM32F042 devices)
* If a reset circuit is present, tap the RESET button
* Otherwise, you need to bridge BOOT0 to VCC (via BOOT0 button or bridge), short RESET to GND (via RESET button or bridge), and then let go of the BOOT0 bridge
* If a reset circuit is present, tap the `RESET` button on the PCB; some boards may also have a toggle switch that must be flipped
* Otherwise, you need to bridge `BOOT0` to VCC (via `BOOT0` button or jumper), short `RESET` to GND (via `RESET` button or jumper), and then let go of the `BOOT0` bridge
2. Wait for the OS to detect the device
3. Flash a .bin file
* You will receive a warning about the DFU signature; Just ignore it
4. Reset the device into application mode (may be done automatically)
* If you are building from command line (e.g. `make planck/rev6:default:dfu-util`), make sure that `:leave` is passed to the `DFU_ARGS` variable inside your `rules.mk` (e.g. `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) so that your device resets after flashing
### STM32 Commands
### `make` Targets
There are a number of DFU commands that you can use to flash firmware to a STM32 device:
*`:dfu-util`: Waits until an STM32 bootloader device is available, and then flashes the firmware.
*`:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:avrdude`, but also sets the handedness setting in EEPROM. This is ideal for Proton-C-based split keyboards.
*`:st-link-cli`: Allows you to flash the firmware via the ST-Link CLI utility, rather than dfu-util. Requires an ST-Link dongle.
*`:st-flash`: Allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util. Requires an ST-Link dongle.
*`:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader device is present.
*`: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.
## STM32duino
This bootloader is used almost exclusively for STM32F103 boards, as they do not come with a USB DFU bootloader. The source code and prebuilt binaries can be found [here](https://github.com/rogerclarkmelbourne/STM32duino-bootloader).
To ensure compatibility with the STM32duino bootloader, make sure this block is present in your `rules.mk`:
* [dfu-util](https://dfu-util.sourceforge.net/) / `:dfu-util` target in QMK (recommended command line)
Flashing sequence:
1. Enter the bootloader using any of the following methods:
* Tap the `RESET` keycode
* If a reset circuit is present, tap the `RESET` button on the PCB
* Otherwise, you need to bridge `BOOT0` to VCC (via `BOOT0` button or jumper), short `RESET` to GND (via `RESET` button or jumper), and then let go of the `BOOT0` bridge
2. Wait for the OS to detect the device
3. Flash a .bin file
4. Reset the device into application mode (may be done automatically)
## Kiibohd DFU
Keyboards produced by Input Club use NXP Kinetis microcontrollers rather than STM32, and come with their own [custom bootloader](https://github.com/kiibohd/controller/tree/master/Bootloader), however the process and protocol is largely the same.
The `rules.mk` setting for this bootloader is `kiibohd`, but since this bootloader is limited to Input Club boards, it should not be necessary to set at keymap or user level.
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMKFirmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](http://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](http://olkb.com), le clavier [ErgoDox EZ](http://www.ergodox-ez.com), et pour les [produits Clueboard](http://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMKFirmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](https://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](https://olkb.com), le clavier [ErgoDox EZ](https://www.ergodox-ez.com), et pour les [produits Clueboard](https://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé.
## Comment l'obtenir
@@ -29,4 +29,4 @@ Cette commande compilera la révision `rev4` du clavier `planck` avec la disposi
## Comment le personnaliser
QMK a beaucoup de [fonctionnalités](fr-fr/features.md) à explorer, et [une documentation](http://docs.qmk.fm) très abondante que vous pourrez parcourir. La plupart des fonctionnalités vous permettrons de modifier vos [dispositions](fr-fr/keymap.md) (keymaps) et de changer [les codes de caractères](fr-fr/keycodes.md) (keycodes).
QMK a beaucoup de [fonctionnalités](fr-fr/features.md) à explorer, et [une documentation](https://docs.qmk.fm) très abondante que vous pourrez parcourir. La plupart des fonctionnalités vous permettrons de modifier vos [dispositions](fr-fr/keymap.md) (keymaps) et de changer [les codes de caractères](fr-fr/keycodes.md) (keycodes).
QMK est majoritairement écrit en C, avec quelques fonctions et parties spécifiques écrites en C++. Il est destiné aux processeurs intégrés que l'on trouve dans des clavier, particulièrement AVR ([LUFA](http://www.fourwalledcubicle.com/LUFA.php)) et ARM ([ChibiOS](http://www.chibios.com)). Si vous maîtrisez déjà la programmation sur Arduino, vous trouverez beaucoup de concepts et de limitations familiers. Une expérience préalable avec les Arduino n'est pas nécessaire à contribuer avec succès à QMK.
QMK est majoritairement écrit en C, avec quelques fonctions et parties spécifiques écrites en C++. Il est destiné aux processeurs intégrés que l'on trouve dans des clavier, particulièrement AVR ([LUFA](https://www.fourwalledcubicle.com/LUFA.php)) et ARM ([ChibiOS](https://www.chibios.org)). Si vous maîtrisez déjà la programmation sur Arduino, vous trouverez beaucoup de concepts et de limitations familiers. Une expérience préalable avec les Arduino n'est pas nécessaire à contribuer avec succès à QMK.
<!-- FIXME: We should include a list of resources for learning C here. -->
@@ -83,7 +83,7 @@ Limited experimentation on the devices I have available shows that 7 is high eno
La documentation est l'une des manières les plus simples de démarrer la contribution sur QMK. Il est simple de trouver des endroits où la documentation est fausse ou incomplète, et il est tout aussi simple de la corriger! Nous avons aussi grandement besoin de quelqu'un pour éditer notre documentation, donc si vous avez des compétences en édition mais que vous n'êtes pas sûr de savoir où aller, n'hésitez pas [demandez de l'aide](#where-can-i-go-for-help)!
Vous trouverez toute notre documentation dans le répertoire `qmk_firmware/docs`, ou si vous préférez utiliser des outils web, vous pouvez cliquer sur le bouton "Suggest An Edit" en haut de chaque page sur http://docs.qmk.fm/.
Vous trouverez toute notre documentation dans le répertoire `qmk_firmware/docs`, ou si vous préférez utiliser des outils web, vous pouvez cliquer sur le bouton "Suggest An Edit" en haut de chaque page sur https://docs.qmk.fm/.
Lorsque vous donnez des exemples de code dans la documentation, essayez de suivre les conventions de nommage utilisées ailleurs dans la documentation. Par exemple, standardisez les enums en utilisant `my_layers` ou `my_keycodes` afin de garder une consistance:
Sans circuit de réinitialisation vous allez avoir des résultats inconsistants à cause de la mauvaise initialisation du matériel. Regardez le schéma du circuit du TPM754.
## Impossible de lire la colonne de la matrice après 16
@@ -102,7 +102,7 @@ Utilisez `1UL<<16` à la place de `1<<16` dans `read_cols()` du fichier [matrix.
En C, `1` implique un type [int] qui est [16 bits] pour les AVR, ce qui implique que vous ne pouvez pas décaler à gauche de plus de 15. Si vous utilisez `1<<16`, vous aurez un résultat non attendu de zéro. Vous devez donc utiliser un type [unsigned long] en utilisant `1UL`.
## Les touches spéciales ne fonctionnent pas (Touche Système, Touches de contrôle du son)
@@ -122,8 +122,8 @@ Appuyer sur n'importe quelle touche en mode veille devrait sortir l'ordinateur d
**Faites attention au fait que le nommage des pin d'un Arduino diffère de la puce**. Par exemple, la pin `D0` n'est pas `PD0`. Vérifiez le circuit avec la fiche technique.
@@ -12,7 +12,7 @@ Les keycodes sont définies dans [common/keycode.h](https://github.com/qmk/qmk_f
Il existe 3 configurations de clavier standard utilisées dans le monde: ANSI, ISO et JIS. L'Amérique du Nord utilise principalement l'ANSI, l'Europe et l'Afrique l'ISO et le Japon utilise JIS. Les autres régions utilisent généralement ANSI ou ISO. Les keycodes correspondant à ces dispositions spécifiques sont affichés ici :
<!-- Source for this image: http://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
<!-- Source for this image: https://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
## Certaines de mes touches sont permutées ou ne fonctionnent pas
@@ -33,8 +33,8 @@ La touche trouvée sur la plupart des claviers modernes située entre `KC_RGUI`
Utilisez le keycode pour Print Screen (`KC_PSCREEN` or `KC_PSCR`) à la place de `KC_SYSREQ`. La combinaison de touche 'Alt + Print Screen' est reconnue comme 'System request'.
Voir [issue #168](https://github.com/tmk/tmk_keyboard/issues/168) et
* http://en.wikipedia.org/wiki/Magic_SysRq_key
* http://en.wikipedia.org/wiki/System_request
* https://en.wikipedia.org/wiki/Magic_SysRq_key
* https://en.wikipedia.org/wiki/System_request
## Les touches alimentation ne fonctionnent pas
@@ -54,12 +54,12 @@ Les touches de modification ou les calques peuvent être bloquées si la commuta
Pour les touches de modification et les actions de calque, vous devez placer `KC_TRANS` sur la même position du calque de destination afin de désenregistrer la clé de modificateur ou de revenir au calque précédent lors de la libération.
Cette fonctionnalité permet l'usage de *touches à verrouillage mécanique* comme [ces interrupteurs Alps](http://deskthority.net/wiki/Alps_SKCL_Lock). Vous pouvez l'activer en ajoutant ceci à votre `config.h`:
Cette fonctionnalité permet l'usage de *touches à verrouillage mécanique* comme [ces interrupteurs Alps](https://deskthority.net/wiki/Alps_SKCL_Lock). Vous pouvez l'activer en ajoutant ceci à votre `config.h`:
@@ -6,15 +6,15 @@ GitHub peut être un peu compliqué pour ceux qui n'y sont pas familier. Ce guid
Commencez par la [page GitHub de QMK](https://github.com/qmk/qmk_firmware), et vous verrez un bouton dans le coin en haut à droite qui indique "Fork":


Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelques fois prendre un peu de temps), appuyez sur le bouton "Clone or download":


Faites attention à sélectionner "HTTPS", et sélectionnez le lien et copiez-le:


Ensuite, entrez `git clone --recurse-submodules ` dans la ligne de commande, et collez votre lien:
@@ -56,11 +56,11 @@ To https://github.com/whoeveryouare/qmk_firmware.git
Vos changements existent maintenant dans votre fork sur GitHub. Si vous allez à cette adresse (`https://github.com/<whoeveryouare>/qmk_firmware`), vous pouvez créer un nouveau "Pull Request" en cliquant sur ce bouton:
Maintenant, vous pourrez voir exactement ce que vous avez commité. Si ça vous semble bien, vous pouvez le finaliser en cliquant sur "Create Pull Request":
QMK est un firmware Open Source pour votre clavier mécanique. Vous pouvez utiliser QMK pour customiser votre clavier de manière simple et puissante. Tout le monde, du débutant complet au développeur avancé, ont utilisé avec succès QMK pour customiser leur clavier. Ce guide vous aidera à faire de même, quelles que soient vos compétences.
Vous voulez savoir si votre clavier peut utiliser QMK? Si c'est un clavier mécanique que vous avez vous-même construit, il y a de bonnes chances que vous pouvez. Nous supportons un [grand nombre de "hobbyist boards"](http://qmk.fr/keyboards), donc même si votre clavier ne peut pas utiliser QMK, vous ne devriez pas avoir trop de problème pour en trouver un qui vous convienne.
Vous voulez savoir si votre clavier peut utiliser QMK? Si c'est un clavier mécanique que vous avez vous-même construit, il y a de bonnes chances que vous pouvez. Nous supportons un [grand nombre de "hobbyist boards"](https://qmk.fm/keyboards), donc même si votre clavier ne peut pas utiliser QMK, vous ne devriez pas avoir trop de problème pour en trouver un qui vous convienne.
@@ -6,15 +6,15 @@ GitHub can be a little tricky to those that aren't familiar with it - this guide
Start on the [QMK GitHub page](https://github.com/qmk/qmk_firmware), and you'll see a button in the upper right that says "Fork":


If you're a part of an organization, you'll need to choose which account to fork it to. In most circumstances, you'll want to fork it to your personal account. Once your fork is completed (sometimes this takes a little while), click the "Clone or Download" button:


And be sure to select "HTTPS", and select the link and copy it:


From here, enter `git clone --recurse-submodules ` into the command line, and then paste your link:
@@ -56,10 +56,10 @@ To https://github.com/whoeveryouare/qmk_firmware.git
Your changes now exist on your fork on GitHub - if you go back there (`https://github.com/<whoeveryouare>/qmk_firmware`), you can create a "New Pull Request" by clicking this button:
@@ -14,16 +14,32 @@ The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`,
The `<target>` means the following
* If no target is given, then it's the same as `all` below
*`all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck.
*`flash`, `dfu`, `teensy`, `avrdude`, `dfu-util`, or `bootloadHID` compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
* **Note**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default:flash`.
*`flash`, `dfu`, `teensy`, `avrdude`, `dfu-util`, or `bootloadHID` compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme.
Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
* **Note**: some operating systems need privileged access for these commands to work. This means that you may need to setup [`udev rules`](faq_build.md#linux-udev-rules) to access these without root access, or to run the command with root access (`sudo make planck/rev4:default:flash`).
*`clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems.
*`distclean` removes .hex files and .bin files.
The following targets are for developers:
*`show-path` shows the path of the source and object files.
*`dump-vars` dumps the makefile variable.
*`objs-size` displays the size of individual object files.
*`show_build_options` shows the options set in 'rules.mk'.
*`check-md5` displays the md5 checksum of the generated binary file.
You can also add extra options at the end of the make command line, after the target
*`make COLOR=false` - turns off color output
*`make SILENT=true` - turns off output besides errors/warnings
*`make VERBOSE=true` - outputs all of the gcc stuff (not interesting, unless you need to debug)
*`make EXTRAFLAGS=-E` - Preprocess the code without doing any compiling (useful if you are trying to debug #define commands)
*`make VERBOSE_LD_CMD=yes` - execute the ld command with the -v option.
*`make VERBOSE_AS_CMD=yes` - execute the as command with the -v option.
*`make VERBOSE_C_CMD=<c_source_file>` - add the -v option when compiling the specified C source file.
*`make DUMP_C_MACROS=<c_source_file>` - dump preprocessor macros when compiling the specified C source file.
*`make DUMP_C_MACROS=<c_source_file> > <logfile>` - dump preprocessor macros to `<logfile>` when compiling the specified C source file.
*`make VERBOSE_C_INCLUDE=<c_source_file>` - dumps the file names to be included when compiling the specified C source file.
*`make VERBOSE_C_INCLUDE=<c_source_file> 2> <logfile>` - dumps the file names to be included to `<logfile>` when compiling the specified C source file.
The make command itself also has some additional options, type `make --help` for more information. The most useful is probably `-jx`, which specifies that you want to compile using more than one CPU, the `x` represents the number of CPUs that you want to use. Setting that can greatly reduce the compile times, especially if you are compiling many keyboards/keymaps. I usually set it to one less than the number of CPUs that I have, so that I have some left for doing other things while it's compiling. Note that not all operating systems and make versions supports that option.
Image from [RoastPotatoes' "How to hand wire a Planck"](https://blog.roastpotatoes.co/guide/2015/11/04/how-to-handwire-a-planck/)
But the larger and more complicated your keyboard, the more complex the matrix. [Keyboard Firmware Builder](https://kbfirmware.com/) can help you plan your matrix layout (shown here with a basic fullsize ISO keyboard imported from [Keyboard Layout Editor](http://www.keyboard-layout-editor.com).
But the larger and more complicated your keyboard, the more complex the matrix. [Keyboard Firmware Builder](https://kbfirmware.com/) can help you plan your matrix layout (shown here with a basic fullsize ISO keyboard imported from [Keyboard Layout Editor](https://www.keyboard-layout-editor.com).

@@ -76,9 +76,9 @@ Established materials and techniques include:
| :-----------| :------- | :------ | :--- | :---
| Lengths of wire with stripped segments | [Sasha Solomon's Dactyl](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f) and [Cribbit's modern hand wire](https://geekhack.org/index.php?topic=87689.0) | Neat and tidy | Some effort in stripping the wire | 
| Short lengths of wire | [u/xicolinguada's ortho build](https://www.reddit.com/r/MechanicalKeyboards/comments/c39k4f/my_first_hand_wired_keyboard_its_not_perfect_but/) | Easier to strip the wire | More difficult to place | 
| Magnet/Enamelled wire | [Brett Kosinski's handwired alpha](http://blog.b-ark.ca/Blog-2019-01-27) and [fknraiden's custom board](https://geekhack.org/index.php?topic=74223.0) | Can be directly soldered onto (insulation burns off with heat) | Appearance? | 
| Magnet/Enamelled wire | [fknraiden's custom board](https://geekhack.org/index.php?topic=74223.0) | Can be directly soldered onto (insulation burns off with heat) | Appearance? | 
| Bending the legs of the diodes for the rows | [Matt3o's Brownfox](https://deskthority.net/viewtopic.php?f=7&t=6050) | Fewer solder joints required | Uninsulated | 
| Using ridid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
| Using rigid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
| Bare wire with insulation added after (e.g. kapton tape) | [Matt3o's 65% on his website](https://matt3o.com/hand-wiring-a-custom-keyboard/) | Easier (no wire stripping required) | Not as attractive | 
| Copper tape | [ManuForm Dactyl](https://github.com/tshort/dactyl-keyboard) | Very easy | Only really works when your plate/case aligns with the bottom of your switches | 
@@ -121,7 +121,7 @@ Letting the diode rest, grab your solder, and touch both it and the soldering ir
The smoke that the rosin releases is harmful, so be careful not to breath it or get it in your eyes/face.
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiny) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blow on it will accelerate this process.
After soldering things in place, it may be helpful to blow on the joint to push the smoke away from your face, and cool the solder quicker. You should see the solder develop a matte (not shiny) surface as it solidifies. Keep in mind that it will still be very hot afterwards, and will take a couple minutes to be cool to touch. Blowing on it will accelerate this process.
When the first diode is complete, the next one will need to be soldered to both the keyswitch, and the previous diode at the new elbow. That will look something like this:
@@ -175,7 +175,7 @@ As you move along, be sure that the controller is staying in place - recutting a
From here, you should have a working keyboard once you program a firmware.
Simple firmware can be created easily using the [Keyboard Firmware Builder](https://kbfirmware.com/) website. Recreate your layout using [Keyboard Layout Editor](http://www.keyboard-layout-editor.com), import it and recreate the matrix (if not already done as part of [planning the matrix](#planning-the-matrix).
Simple firmware can be created easily using the [Keyboard Firmware Builder](https://kbfirmware.com/) website. Recreate your layout using [Keyboard Layout Editor](https://www.keyboard-layout-editor.com), import it and recreate the matrix (if not already done as part of [planning the matrix](#planning-the-matrix).
Go through the rest of the tabs, assigning keys until you get to the last one where you can compile and download your firmware. The .hex file can be flashed straight onto your keyboard, and the .zip of source files can be modified for advanced functionality and compiled locally using the method described in [Building Your First Firmware](newbs_building_firmware?id=build-your-firmware).
@@ -205,7 +205,7 @@ Plug in your keyboard and press the reset button (or short the Reset and Ground
## Testing Your Firmware
Use a website such as [QMK Configurator's Keyboard Tester](https://config.qmk.fm/#/test), [Keyboard Tester](https://www.keyboardtester.com/tester.html), or [Keyboard Checker](http://keyboardchecker.com/) or just open a text editor and try typing - you should get the characters that you put into your keymap. Test each key, and make a note of the ones that aren't working. Here's a quick trouble-shooting guide for non-working keys:
Use a website such as [QMK Configurator's Keyboard Tester](https://config.qmk.fm/#/test), [Keyboard Tester](https://www.keyboardtester.com/tester.html), or [Keyboard Checker](https://keyboardchecker.com/) or just open a text editor and try typing - you should get the characters that you put into your keymap. Test each key, and make a note of the ones that aren't working. Here's a quick trouble-shooting guide for non-working keys:
1. Flip the keyboard back over and short the keyswitch's contacts with a piece wire - this will eliminate the possibility of the keyswitch being bad and needing to be replaced.
2. Check the solder points on the keyswitch - these need to be plump and whole. If you touch it with a moderate amount of force and it comes apart, it's not strong enough.
@@ -224,7 +224,7 @@ Once you have confirmed that the keyboard is working, if you have used a seperat
If you found this fullfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/)
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](http://docs.qmk.fm) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](http://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/Uq7gcHh) for help!
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](https://docs.qmk.fm) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](https://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/Uq7gcHh) for help!
## Links to Other Guides
@@ -232,7 +232,7 @@ There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](htt
- [Cribbit's "Modern hand wiring guide - stronger, cleaner, easier"](https://geekhack.org/index.php?topic=87689.0)
- [Sasha Solomon's "Building my first Keyboard"](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f)
- [RoastPotatoes' "How to hand wire a Planck"](https://blog.roastpotatoes.co/guide/2015/11/04/how-to-handwire-a-planck/)
@@ -32,7 +32,7 @@ This will create all the files needed to support your new keyboard, and populate
## `readme.md`
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates.md#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](http://imgur.com) to host the images.
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates.md#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](https://imgur.com) to host the images.
## `<keyboard>.c`
@@ -77,7 +77,7 @@ Do change the `MANUFACTURER` and `PRODUCT` lines to accurately reflect your keyb
#define PRODUCT my_awesome_keyboard
```
?> Windows and macOS will display the `MANUFACTURER` and `PRODUCT` in the list of USB devices. `lsusb` on Linux instead takes these from the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html) by default. `lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
?> Windows and macOS will display the `MANUFACTURER` and `PRODUCT` in the list of USB devices. `lsusb` on Linux instead prefers the values in the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html). By default, it will only use `MANUFACTURER` and `PRODUCT` if the list does not contain that `VENDOR_ID` / `PRODUCT_ID`. `sudo lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
@@ -183,7 +183,7 @@ As an example, if you have a 60% PCB that supports ANSI and ISO you might define
In an effort to keep the repo size down we're no longer accepting binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred.
Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](http://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `http://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split` folder for an example.
Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](https://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `https://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split` folder for an example.
## Keyboard Defaults
@@ -225,7 +225,7 @@ The year should be the first year the file is created. If work was done to that
## License
The core of QMK is licensed under the [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). If you are shipping binaries for AVR processors you may choose either [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or [GPLv3](https://www.gnu.org/licenses/gpl.html). If you are shipping binaries for ARM processors you must choose [GPL Version 3](https://www.gnu.org/licenses/gpl.html) to comply with the [ChibiOS](http://www.chibios.org) GPLv3 license.
The core of QMK is licensed under the [GNU General Public License](https://www.gnu.org/licenses/licenses.en.html). If you are shipping binaries for AVR processors you may choose either [GPLv2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) or [GPLv3](https://www.gnu.org/licenses/gpl.html). If you are shipping binaries for ARM processors you must choose [GPL Version 3](https://www.gnu.org/licenses/gpl.html) to comply with the [ChibiOS](https://www.chibios.org) GPLv3 license.
If your keyboard makes use of the [uGFX](https://ugfx.io) features within QMK you must comply with the [uGFX License](https://ugfx.io/license.html), which requires a separate commercial license before selling a device containing uGFX.
QMK (*Quantum Mechanical Keyboard*) היא קהילת קוד פתוח (open source) שמתחזקת את קושחת QMK, QMK Toolbox, qmk.fm, והמסמכים המתאימים. קושחת QMK היא קושחה עבור מקלדות המבוססת על [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) עם כמה תוספות עבור בקרי Atmel AVR ובאופן ספציפי יותר - [מוצרי OLKB](http://olkb.com), מקלדת [ErgoDox EZ](http://www.ergodox-ez.com), וגם [מוצרי Clueboard](http://clueboard.co/). בנוסף, הקושחה עברה פורט עבור שבבי ARM באמצעות ChibiOS. ניתן להשתמש בה על מנת להפעיל את מקלדות ה PCB המקוסטמות שלך.
QMK (*Quantum Mechanical Keyboard*) היא קהילת קוד פתוח (open source) שמתחזקת את קושחת QMK, QMK Toolbox, qmk.fm, והמסמכים המתאימים. קושחת QMK היא קושחה עבור מקלדות המבוססת על [tmk\_keyboard](https://github.com/tmk/tmk_keyboard) עם כמה תוספות עבור בקרי Atmel AVR ובאופן ספציפי יותר - [מוצרי OLKB](https://olkb.com), מקלדת [ErgoDox EZ](https://www.ergodox-ez.com), וגם [מוצרי Clueboard](https://clueboard.co/). בנוסף, הקושחה עברה פורט עבור שבבי ARM באמצעות ChibiOS. ניתן להשתמש בה על מנת להפעיל את מקלדות ה PCB המקוסטמות שלך.
## איך להשיג אותה
@@ -30,5 +30,5 @@ QMK (*Quantum Mechanical Keyboard*) היא קהילת קוד פתוח (open sour
## איך להתאים
לQMK יש המון [יכולות](he-il/features.md) שאפשר לנווט בהן, וכמות נכבדת של [תיעוד ודוקומנטציה](http://docs.qmk.fm) בה אפשר לנבור. רוב הפיצ׳רים באים לידי ביטוי על ידי שינוי [מיפוי המקלדת](he-il/keymap.md) ושינוי [קודי המקשים](he-il/keycodes.md).
לQMK יש המון [יכולות](he-il/features.md) שאפשר לנווט בהן, וכמות נכבדת של [תיעוד ודוקומנטציה](https://docs.qmk.fm) בה אפשר לנבור. רוב הפיצ׳רים באים לידי ביטוי על ידי שינוי [מיפוי המקלדת](he-il/keymap.md) ושינוי [קודי המקשים](he-il/keycodes.md).
@@ -7,15 +7,15 @@ GitHub עלול להיות קצת טריקי למי שלא מכיר את העב
התחילו ב- [עמוד של QMK ב-GitHub](https://github.com/qmk/qmk_firmware), ותצמאו כפתור בחלק העליון מימין עם התיכוב "Fork":


אם אתם חלק מארגון, תצטרכו לבחור לאיזה חשבון לבצע פעולת fork. ברוב המבקרים, תרצו לבצע fork לתוך החשבון הפרטי שלכם. ברגע שה-fork הסתיים (לפעמים זה יכול לקחת קצת זמן) הקליקו על כפתור ה-"Clone or Download":
תוודאו שאתם בוחרים באופצייה של "HTTPS", בחרו את הקישור והעתיקו אותו:


מכאן והלאה, הקיש `git clone --recurse-submodules ` בשורת הפקודה והדביקו את הלינק שלכם:
@@ -65,11 +65,11 @@ To https://github.com/whoeveryouare/qmk_firmware.git
השינויים שלכם יופיעו ב-fork שלכם ב-GitHub - אם תחזרו לשם (`https://github.com/<whoeveryouare>/qmk_firmware`), תוכלו ליצור "Pull Request חדש" ע״י הקשה על הכפתור הבא:
QMK רצה על מגוון של חומרות. אם המעבד שלך יכול להיות ממוקד (מטורגט) ע״י [LUFA](http://www.fourwalledcubicle.com/LUFA.php) או [ChibiOS](http://www.chibios.com) כנראה שתוכל לגרום ל QMK לרוץ על המעבד. קטע זה מדבר על הרצת QMK, ותקשורת עם, סוגים שונים של חומרות.
QMK רצה על מגוון של חומרות. אם המעבד שלך יכול להיות ממוקד (מטורגט) ע״י [LUFA](https://www.fourwalledcubicle.com/LUFA.php) או [ChibiOS](https://www.chibios.org) כנראה שתוכל לגרום ל QMK לרוץ על המעבד. קטע זה מדבר על הרצת QMK, ותקשורת עם, סוגים שונים של חומרות.
@@ -20,7 +20,7 @@ The following functions can provide basic control of GPIOs and are found in `qua
## Advanced Settings :id=advanced-settings
Each microcontroller can have multiple advanced settings regarding its GPIO. This abstraction layer does not limit the use of architecture-specific functions. Advanced users should consult the datasheet of their desired device and include any needed libraries. For AVR, the standard avr/io.h library is used; for STM32, the ChibiOS [PAL library](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
Each microcontroller can have multiple advanced settings regarding its GPIO. This abstraction layer does not limit the use of architecture-specific functions. Advanced users should consult the datasheet of their desired device and include any needed libraries. For AVR, the standard avr/io.h library is used; for STM32, the ChibiOS [PAL library](https://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
If you are using a different controller or want different configuration, you can use [this AVR Fuse Calculator](http://www.engbedded.com/fusecalc/) to find a better value for you.
If you are using a different controller or want different configuration, you can use [this AVR Fuse Calculator](https://www.engbedded.com/fusecalc/) to find a better value for you.
世界中で使用されている ANSI、ISO および JIS の3つの標準キーボードがあります。北米では主に ANSI が使われ、ヨーロッパおよびアフリカでは主に ISO が使われ、日本では JIS が使われます。言及されていない地域では、ANSI あるいは ISO が使われています。これらのレイアウトに対応するキーコードは以下の通りです:
<!-- Source for this image: http://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
<!-- Source for this image: https://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
これで、キーボードへの HID インタフェースを開くために必要な4つの情報全てが揃いました。必要なのは、ライブラリの利用可能な関数を使って ID パラメータを使ってデバイスを開くことだけです。
Vendor ID と Product ID はデバイスを開くために実際には必要ないことに注意してください。それらは接続した多くの HID デバイスから特定のデバイスをフィルターするためだけに使われます。多くのライブラリでは、代わりに製品名と製造元名を使ってデバイスを開くオプションがあります。`node-hid` が代表的な例です。これは USB ハブが組み込まれているデバイスや、同じ製品名または同じ製造元の複数のインタフェースがある特別な HID インタフェースで問題になります。Product ID と Vendor ID を合わせると単一のインタフェースの固有名を作成できるため、この問題を防げます。したがって、ライブラリで必要が無い場合でも、この問題を防ぐためにそれらを使うことをお勧めします。
ただし、Vendor ID や Product ID と異なり、Usage Page と Usage は通信を成功させるために必要です。
インストールは非常に簡単です: [5 Steps to install Eclipse](https://eclipse.org/downloads/eclipse-packages/?show_instructions=TRUE) に従い、ステップ3で **Eclipse IDE for C/C++ Developers** を選択します。
あるいは、直接 [Eclipse IDE for C/C++ Developers をダウンロード](http://www.eclipse.org/downloads/eclipse-packages/)([現在のバージョンへの直接リンク](http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/neonr))し、選択した場所にパッケージを解凍することもできます (これにより `eclipse` フォルダが作成されます)。
あるいは、直接 [Eclipse IDE for C/C++ Developers をダウンロード](https://www.eclipse.org/downloads/eclipse-packages/)([現在のバージョンへの直接リンク](https://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/neonr))し、選択した場所にパッケージを解凍することもできます (これにより `eclipse` フォルダが作成されます)。
これは最も重要なプラグインで、Eclipse が AVR C コードを_理解_できるようになります。[更新サイトを使うための指示](http://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download#Update_Site)に従い、未署名コンテンツのセキュリティ警告に同意します。
これは最も重要なプラグインで、Eclipse が AVR C コードを_理解_できるようになります。[更新サイトを使うための指示](https://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download#Update_Site)に従い、未署名コンテンツのセキュリティ警告に同意します。
### [ANSI Escape in Console](https://marketplace.eclipse.org/content/ansi-escape-console)
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.