* Formatting of Contra readme.
* Initial version of my custom keymap
* Move TODOs to readme
* Add comment
* Nuke Plover layer
* Port changes to other layers
* Finished work on my own layout for now
* Add layout image
* Processed comments from review
* Set proper AVR part for USBasp avrdude flashing
* Remove `PROGRAM_CMD` stuff from rules.mk as they should not be needed anymore
* Missed the Plaid readme
* Remove PROGRAM_CMD from Mysterium
* Display logo for caps lock indication on crkbd using old OLED driver
* Add emacs read-only mode file variable to generated files
* use LTO_ENABLE instead of EXTRAFLAGS
This enables the same option, and disables action_macros, and action_functions, both of which seem to break when LTO is enabled. And this is a lot simpler to use.
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* fix instructions for oneshot layer handling on key release
* use ONESHOT_OTHER_KEY_PRESSED instead of ONESHOT_PRESSED
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Improve support and docs for ADC driver
* Comment ADC channels
* Move to Makers and Modders section, and fix usage instructions
* Flesh out intro
* Superscript 328P note
* Fix pin_to_mux LUT
* Support USB64/1287 as well
* analogReadPin() defaults to 0V mux on invalid pin
* Update pinToMux() function documentation
* Dot
* Accept (some of) the `qmk cformat` changes
* Do clang-format properly
* More wording tweaks
* Link to encoder docs
* Update getting_started_make_guide.md
clarifying that NO_PRINT and USER_PRINT should not be used at the same time.
* Update docs/getting_started_make_guide.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Added my Dactyl Manuform layout
* Added my Dactyl Manuform layout
* finalized key layout, added reset code, no LED yet
* finalized key layout, added reset code, no LED yet
* enabled RGB backlight
* enabled RGB backlight
* enabled RGB backlight
* supporting split rgb
* supporting split rgb
* supporting split rgb
* added media controls
* allowing ctrl/command to fallthrough from mouse layer so we can ctrl scroll to zoom in/out
* addressed PR comments, and make a couple last minute adjustments to the layout, to add in the Forwards Delete keycode
* decreased brightness even more
* massdrop ctrl endgame keymap first commit
* massdrop ctrl endgame keymap update
Added double dance functions to toggle mouse layer while keeping LGUI key functionality.
Added led config and related functionality.
Added RGB indicators for effective keys on layers.
Fixed RGB timeout ignoring user set LED flags.
At current state, layer RGB indicators ignore RGB brightness value, will add toggle key later to toggle between current keyboard brightness and max brightness as it's nice to have the indicator RGB at max brightness but still too bright at times.
* updated documentation and added RGB indicator for ctrl and shift in function layer
* Update keyboards/massdrop/ctrl/keymaps/endgame/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update keyboards/massdrop/ctrl/keymaps/endgame/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Various fixes and changes.
Removed backslashed at end of layouts, better looking.
Changed layout names from macro definitions to enum.
Replaced MOD_BIT with MOD_MASK macros.
* add RGBRST key into helix/pico:default keymap ADJUST layer
* update helix/rev2:default keymap's OLED display contents
* add RGBRST key to HELIX_ROWS == 4 ADJUST layer
* add CAPS key to RAISE, LOWER layer
* add layer status display on slave side oled
* add RGB LED status display on both side oled
* save stack memory size
* Add "Resynchronizing an Out-of-Sync Git Branch" doc
* Update (Git) Best Practices doc title and filename
* Rename Branch Resync doc
* fork Best Practices doc into multiple files
* Add the doc list to Git Best Practices doc
* Update sidebar
* Update internal references
* Update sidebar - add subsection
* Update Your Fork's Master page title
* title case on Git Best Practices main doc
* ... and in the Resynchronizing a Branch doc
* Please read Part 1
I worked really hard on this, okay?
* Please use branches, too.
* suggestions by mtei
* change note about adding multiple files
* note that the name given the remote repo is arbitrary
* suggestions by fauxpark
* Git Best Practices -> Best Git Practices
Reads more naturally.
* rephrase hint block regarding remote name
* rework the resynchronization instructions per mtei
* use hint boxes for reference to Part 1 doc
I may be addicted to hint boxes. I'm sorry fauxpark. 😢
* add some clarity about the upstream repo
* wordsmithing per mtei
* restyle the shell code blocks
Makes them more consistent to the other docs in this section.
* Added tr60w configurations.
I based these files on the fox-lab/qmk_firmware repository.
After checking both licenses, which are identical, I added those
files into this feature branch.
For transparency reasons I'll add the url to the fox-lab repository.
https://github.com/fox-lab/qmk_firmware
* Using #pragma once in config.h.
* Removed '#define CCONFIG_H' from config.h.
* Changed PRODUCT_ID to '0x4140'.
* Renamed setting to 'DEBOUNCE'.
* Removed key combination, due to already default implementation.
* Removed 'PREVENT_STUCK_MODIFIERS', defaulted by QMK.
* Removed not uneccessary '#endif' statement.
* Renamed include to 'QMK_KEYBOARD_H'.
* Changed keymap structure according to pull request suggestion.
* Removed 'void matrix_init_user(void)'.
* Removed 'void matrix_scan_user(void)'.
* Removed 'bool process_record_user(...)'.
* Removed non-standard configuration in favor for 'led_update_kb'.
* Using default setup based on 'MCU' setting.
* Replaced Build Option configuration with suggested information.
* Fixed include statements as requested.
* Changed 'KEYMAP' to suggestion.
* Removed obsolete '#endif' statement.
* Added readme.md file.
* Updated readme.md with further information.
* Reverted include statement, to check if this caused ci error.
* Revert "Reverted include statement."
This reverts commit ebd992dc01133169be38ae7201bb00b4d01cc737.
* Fixed wrong mapped key
* Fixed include as per suggestion.
* Replaced 'KC_TRNS' with '_______'for readability.
* Added personal keymap.c file.
* Updated the readme.md file according to template/avr/readme.md.
* Fixed Link to Image.
* Updated readme.md as per request.
* Updated rules.mk, as per suggestion.
Set 'BOOTMAGIC_ENABLE = lite'.
* for initial commit
* for initial commit
* for initial commit
* Update led_update_kb example (#7451)
* Update led_update_kb example
* Update comment to explain pin behavior
* wordsmith
* wordsmithing 2
* Remove CR when computing BOOTLOADER_SIZE. (#7453)
* Set up language fallback for docs, and update translation guidelines (#7403)
* Set up language fallback for docs, and update translation guidelines
* Title Case
* Add ID example
* Link to emoji flag cheatsheet
* Move docs preview section to contributing.md
* Point to docs preview in the readme
* [Keyboard] Added Cans12er keyboard (#7455)
* added cans12er keyboard
* updated readme
Updated the readme to conform with the provided template from the qmk_firmware githubpage
* Update keyboards/cans12er/README.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Changed configuration
Changed the configuration based on the Change Request from PR #7455 made by github user noroadsleft
* [Keyboard] Update ATmega32A readme files to match template (#7462)
* Update atmega32a readme files to match template
* Update atmega32a readme files to match template - fixes
* Apply suggestions from code review
* update files based on comments
* update files based on comments
* update files based on comments
* update files based on comments
* update files based on comments
* update files based on comments
* update files based on comments
Co-Authored-By: Takeshi ISHII <2170248+mtei@users.noreply.github.com>
Co-Authored-By: shela <shelaf@users.noreply.github.com>
* fluorite keymaps
* Update config.h
* Update fluorite.c
I corrected the points that were pointed out.
* Update fluorite.h
I corrected the points that were pointed out.
* Update config.h
I corrected the points that were pointed out.
* Update keymap.c
I corrected the points that were pointed out.
* Update keyboards/fluorite/config.h
thanks!
* Update keyboards/fluorite/readme.md
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/readme.md
thanks!
* Update keyboards/fluorite/readme.md
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keyboards/fluorite/rules.mk
thanks!
* Update keymap.c
I corrected the points that were pointed out.
* Update fluorite.c
I corrected the points that were pointed out.
* Update rules.mk
I corrected the points that were pointed out.
* Update keyboards/fluorite/rules.mk
Thanks!
* Update keyboards/fluorite/rules.mk
Thanks!
* Update keymap.c
I corrected the points that were pointed out.
* Update fluorite.h
I corrected the points that were pointed out.
* Update keymap.c
I corrected the points that were pointed out.
* Update keymap.c
I corrected the points.
c:165:68
XDXXXXX >> XXXXXXX
Reverted,because error log.
ADJUST,
* Update keymap.c
I corrected the points that were pointed out.
* Update readme.md
link added
* Update readme.md
photo link added
* Update readme.md
link Modify
* Update keyboards/fluorite/readme.md
Thanks!
* Update keyboards/fluorite/readme.md
Thanks!
* Fix linux install for Ubuntu. It failed due to sh not supporting [ and pip being seperate from python3
* Adapted install function according to feedback
* Fix style
* fixed noah info.json
* fixed iso keymap and adding default iso keymaps
* keymap cleanup
* verified through the qmk configurator preview mode
* modify encoding from utf-8 bom to urf-8
* replace home and end with cmd-left and cmd-right for iOS compatability
* tab left and right with cmd-shift-bracket instead of ctrl-tab for Blink compatability
* cmd-up and cmd-down instead of pg-up pg-down for blink shell compatability
* Revert "cmd-up and cmd-down instead of pg-up pg-down for blink shell compatability"
This reverts commit e976af9f11f77933f272edc22faf971445a65717.
* reorganised symbol layer
* update link in readme
* Add shift-to-invert to remaining directional RGB_* keycode pairs
RGB_MODE_FORWARD / RGB_MODE_REVERSE invert their functions when shift is held.
This change adds the same capabilities to the remaining directional RGB_*
keycode pairs. This improves consistency and provides full RGB control in a
keymap containing only one keycode from each pair.
* remove redundant variable
* fix typo
* Fix more typos
Flyspell is on now I swear!
* Install bootloadHid on macos
* Install bootloadHid on windows
* Highlight bootloadHID is now installed in docs
* Update udev rules for bootloadHID
* Install bootloadHid on some distros
* fix caterina udev filename
* Community Layout support for KBD8X MK2
- add LAYOUT_tkl_ansi and LAYOUT_tkl_iso layout macros
- add default_tkl_iso keymap, using new layout macro
- rename ansi_625 keymap to default_tkl_ansi, using new layout macro
- change keymaps to four-space indent
- update info.json
- remove firmware size impacts from rules.mk
* remove empty functions
* rename the ANSI and ISO keymaps per fauxpark
* idea
* progress
* more stuff
* wip
* wip
* last couple of keycodes you can move safely
* Update quantum/quantum.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Put back RGB_MODE_BREATHE
* add new keyborad wm1
* 删除print信息
* add info.json and modified the default keymap.c
* add keyboard name and maintainer in info.json
* add readme.md file for new keyboard
* add default/keymap/readme.md
* modified the main readme file
* change keyboard name from wm1 to wm1_hotswap
* update readme
* update imgur link in readme
* update readme to add more pic and subtopic
* change wm1 keyboard pic to direct show up
* add copyright to config.h
* modified the info.json to change the label
* set the debug config to no in rule.mk
* rename wn1.c wm1.h to wm1_hotswap.c, wm1_hotswap.h
* fix spelling mistake
* update the rule.mk to new version
* fix the LED operation in wm1_hotswap.c
* delete the definition of kc_trns
* change layout to conform to electrical position
* delete backslashes in keymap.c
* update info.json according to the layout
* change the return of led_update_kb
* delete unused comments in rule.mk
* delete unused definition in wm1_hotswap.h
* add a if statement to support user override func
* fix comment in rules.mk
* IS31FL3733 Dirty page fix
Function IS31FL3733_update_led_control_registers was never setting update register to false. As a result the led on/off page was being written every transaction even when it was not modified. This is ineficient and causes lots of bandwidth use.
-> Fix the IS31FL3733_update_led_control_registers.
-> After testing it was evident that failed I2C transactions could corrupt the Led on/off register.
-> Update IS31FL3733_write_pwm_buffer and IS31FL3733_write_register functions to return 0 upon succesful tranmission and 1 if any of the transmitions within the function fail.
-> Modify IS31FL3733_update_pwm_buffers function so if any of the IS31FL3733_write_pwm_buffer transuction fails, the g_led_control_registers_update_required register is set to true forcing a rewrite of the led on/off register in case it was corrupted.
* Minor comment update
* Upsie:)
* Update is31fl3733.c
* Return fix
* more return fix
* type change
* more boolian logic reversal:)
* Add left number pad layout to candybar keyboard
* successfully builds
* Rename new layout to LAYOUT_lefty and add corresponding LAYOUT_righty as alias for LAYOUT
* merge
* Add lefty keymap
* Add lefty layout to info.json
* Added LAYOUT_righty to info.json and corrected some misplaced braces
* Update keyboards/candybar/info.json
* removed redundant sections as suggested.
* added cans12er keyboard
* updated readme
Updated the readme to conform with the provided template from the qmk_firmware githubpage
* Update keyboards/cans12er/README.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Changed configuration
Changed the configuration based on the Change Request from PR #7455 made by github user noroadsleft
* Set up language fallback for docs, and update translation guidelines
* Title Case
* Add ID example
* Link to emoji flag cheatsheet
* Move docs preview section to contributing.md
* Point to docs preview in the readme
* f
* Allow overriding of all functions in wonderland.c
- needed for custom LED functions in keymap.c
* Example of layer indication via LEDs
optimize
* Use newer led_update_kb and led_update_user hooks
- these allow overriding without use of __attribute((weak))__
* Update led documentation a bit
- clarify some of the wording around how to use led_update_user
* Update led_update_user example
* Update audio example to be complete
* trailing spaces smh
* spaces
* spaces
* smh
* Less code is good
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update docs/custom_quantum_functions.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Make MSYS force install
* Cleanup msys script
* Update to gcc 8.3 for arm and avr
And cleanup install scripts for both
* Fix path and scripts
* Fix links
* No confirmation for msys
* Tweak arm function since file structure changed
* Fix spacing and wording
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Only use MSYS2's make binary
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Some wordsmithing
Co-Authored-By: Mikkel Jeppesen <2756925+Duckle29@users.noreply.github.com>
* Add "disable download timeout" for download issues in MSYS
Co-Authored-By: Mikkel Jeppesen <2756925+Duckle29@users.noreply.github.com>
* Clean up URL for arm gcc download
Co-Authored-By: Joel Challis <git@zvecr.com>
* add pip
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Add three missing default layouts
* Add layout support to tragicforce68
* Not really 68%
* Fix dumb mistake
* Update info.json too
* Apply suggestions from code review
* MILC: Add support for hidden subcommands
Subcommands with 'hidden=True' will not show up in the help output, but
will work as any other subcommands.
* Hide those hidden submodules, for real now
* Rebase on latest MILC
* Change label for stale bot
* Reword things to be more concise and clear
* git add . -- that's how this works, right?
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Remove Discussion label from issue templates
* Adds layout for DZ60rev2 plate B, options 4 and 10
* Use KC_TRANS for layer keys
* Format layer0 with visual key size layout
* Add RGB controls; add start description; add KC_LOCK
* Update comments on rules.mk for DZ60
* Gets keymap compiling
* Fix wiring for shift on row 3
* Hold a with other key to send Ctrl-A before other key
* Adds compile-time defined mac-compatability media keycodes
* Adds logic in place for capturing taps (w/ timeout)
* Add send_keys(...) which can send up to 64 nested keycodes
* Implement send_keys callable with n repeats
* Tweaks some of the keymap
* Add reset keycode; add disable to custom shortcuts
* Adds a special "off" layer where bonus mod goes to layer 0, every other key KC_NO
* Adjust timeout; mousekey settings
* Changes layout of Home,End,PgUp/Dn on the dedicated arrow keys L1/L2
* PoC on rgb lighted layer indication
* Refactors color table defines
* Adds logic for controlling layer lights
* Only change state on one side of the event lol
* Switch back to Tapping Toggle for layer 4
* Add custom config file for keyboard; TT and mousekey settings
* Code cleanup; starting to refactor special ctrl tapping keys functions
* Move defines and reak out functions
* Remove debugging light
* Adjust keymaps; add enter
* Adds a couple custom macros
* Add simplified version of keymap to help debug issues
* Adds basi numpad configuration for levinson keyboard half
* Use ANSI ctrl key as layer 1 for better one hand (`)
* Adapt to new 8bit hue from #5547; layer enum use everywhere
* Move custom code out to users/ space
* Flip col pins, move key assignments to "left hand"
* Update readme
* Implement placeholder macros
* Notes
* Reduce tapping time for SFT_T(/)
* Adds vim features; refactors things
* Adds fork of the vim features written by xton
* Use correct backspace keycode
* Add VIM_ESC
* Add "OFF" to the RGB/HSV definitions
* Clean up rules, use new "OFF" definition
* Add windows KC_CALCULATOR key to numpad
* Reformat layers with better guide; change layer names
* Add sleep key
* Change timeout delay
* Add a "code paste" which surrounds a ^V with ```
* Try removing shift tap on rshift /
* Update macros
* Update the "code paste" macro
* Update keymap with reset, calc, equals
* Update keyboards/dz60/keymaps/twschum_b_4_10_simple/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update keyboards/dz60/keymaps/twschum_b_4_10/keymap.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update users/twschum/twschum.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Update users/twschum/twschum.c
Co-Authored-By: Drashna Jaelre <drashna@live.com>
* Revert quantum/rgblight_list.h
* Better name for split space layout; rename KEYMAP->LAYOUT
* Rename KEYMAP->LAYOUT
* Use simpler :flash command
* Clean up layout files
* Use qmk's MOD_MASK_CTRL
* Sync lufa submodule
* Cleanup from noroadsleft's PR comments
* Modernize vim layer code
* Update japanese translation of newbs.md and related documents.
* document link id change
* add `ja/` in each link
`[xxx](yyy.md)` --> `[xxx](ja/yyy.md)`
* copy docs/ja/_summary.md from umi-umi's #7248 and fix it
* Remove keymap_config extern from default keymaps
* Revert unicode
Apparently VSCode does not like unicode, I didn't actually edit these lines, so it must have been automatic... :(
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* add the dog keyboard
* set rgbled
* fix info.json and readme.md
* Update keyboards/thedogkeyboard/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/thedogkeyboard/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/thedogkeyboard/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/thedogkeyboard/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* update thedogkeyboard
* Add Kyria Keymap
* Enable all RGBLIGHT Animations for ARM and high capacity AVR
* Reduce GNUC version for __has_include
* Cleanup Ortho 4x12 Community layout
* Update Collide 39 keymap
* Cleanup Keymaps
* Enable full 30 LEDs for Ergodox
* Change EEPROM Load timing
* Use RGB Matrix on Planck Rev6
* Use correct keymap swap
* Enable everything for ARM
* Only enable rgb sleep on avr until crash is fixed
* Add additional Kyria keymap config
* Overhaul Kyria OLED display
* Improve kyria keymap based on usage
* Minor tweaks to rules
* Update OLED code to truncate properly
* Fix RGB Light layer indication
* Switch all of biton32 to get_highest_layer function
* Fix OLED Keylogger display
* Run qmk cformat over all of my user files
* Slight tweak to kyria based on usage
* Move around LALT_T config
* Add comments about base wrappers to keymaps
* Another cformat pass
* Temp fix for VUSB boards and NKRO
* Convert tabs to spaces in rules.mk files
* Only enable RGBLight if it's enabled
* Add Encoder Flip setting
* Update OLED font file
* Add auto-handling of stale PRs/Issues
This adds the configuration for probot-stale, so that PRs and Issues can be automatically pruned without intervention by collaborators.
This marks PRs with `awaiting changes` label after 45 days, and then closes any PR with "Awaiting changes" after 30 days. Unless they have `awaiting review`, `breaking_changes`, `in progress` or `on hold` labels.
This marks issues as `solved` after 90 days, and then closes them 30 days afterwards. Unless they have `bug`, `discussion, `to do`, `in progress` or `on hold` labels.
* Cleanup the text some
* Update .github/stale.yml
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Initial commit
* Fix links so that they point to the german translation
* minor changes to the wording of some sentences
* correctly capitalize second person pronouns
* Fix links so that they point to the german translation
* minor changes to the wording of some sentences
* correctly capitalize second person pronouns
* Translate newbs_learn_more_resources.md
* Clear up some phrases
* Add newbs_building_firmware.md, fix spelling
* Add newbs_building_firmware.md, fix spelling
* Update docs/de/_summary.md
Danke
* Update docs/de/README.md
* Update docs/de/_summary.md
Ich wollte es kuerzer halten damit die Navigationsleiste nicht zu breit wird, aber das ist halt die deutsche Sprache :)
* Update docs/de/newbs.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs.md
* Update docs/de/newbs_learn_more_resources.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs.md
* Update docs/de/newbs.md
* Update docs/de/newbs.md
* Update docs/de/README.md
* Update docs/de/README.md
* Update docs/de/README.md
* Update docs/de/README.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_learn_more_resources.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_learn_more_resources.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_learn_more_resources.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_getting_started.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Update docs/de/newbs_building_firmware.md
* Apply suggestions from code review
* Add translation of newbs_flashing.md
* Apply suggestions from code review
Danke
* Add translation of Zadig-guide
* Translate newbs_testing_debugging.md to german
Co-Authored-By: Max Rumpf <max.rumpf1998@gmail.com>
Co-Authored-By: geisterfurz007 <geisterfurz007@users.noreply.github.com>
* my custom layout
* asd
* use qmk-dfu
* :)
* ganti keymap lagi
* my custom layout
* asd
* use qmk-dfu
* :)
* ganti keymap lagi
* my custom layout
* asd
* use qmk-dfu
* :)
* ganti keymap lagi
* Add handwired2x2 project, define pins for atmega328p in config_common.h
* Add USB IDs
* my custom KBD75 layout
* renaldi danang's numpad
* my redox keymap
* reynaldi danang's numpad
* asdasd
* ASH-1800
* added description and layer 1
* added requested changes from fauxpark
* forgot to include this
* USB descriptor parameter:
- assign product id
- assign description
edit formatting on readme.md
* update USB descriptor: change manufacturer
* review from fauxpark and noroadsleft
* remove extra files
* removed unnecessary comment
* minor cleanup
* Pull in updates for MILC
* Remove the shadow argparser
* Make it easier to reason about arguments and how they're translated into the config tree
* Populate self.config during init to support setting user.qmk_home for the global CLI
* Remove the short argument -c so that we can unambiguously determine the config file location without doing full argument processing
* Remove the --save-config option as it's a little confusing anyway
* Use Pathlib for path manipulation
* Fix commands with no arguments
* [keymap] Add abnt2 format to gh60
* Fix typing errors
* Change key names to capitals
* Fix layout define
* Apply suggestions from code review
* Fix layout define again I used a k
* Remove layer variable
* Update keyboards/dz60/keymaps/default_abnt2/readme.md
* Make changes from noroadsleft
* Add Community Layout: 60_abnt2
Add a 60% version of the standard keyboard layout used in Brazil.
* Enable 60_abnt2 support for DZ60
* fix the indenting in the Community Layout keymap
* debug lint info.json
Because I need to debug this file.
* move ISO Enter to the proper location in sequence
* add key counts because I like having them
A new CLI subcommand was added, flash, which behaves very similar to the already present compile CLI comamnd, but with the added ability to target a bootloader. The command is used like so: qmk flash [-h] [-b] [-kb KEYBOARD] [-km KEYMAP] [-bl BOOTLOADER] [filename].
A -kb <keyboard> and -km <keymap> is expected, or a configurator export JSON filename. A bootloader can be specified using -bl <target>, and if left unspecified, the target is assumed to be :flash. -bl can be used to list the available bootloaders.
If -km <keymap> is provided, but no -kb <keyboard>, then a message is printed suggesting the user to run qmk list_keyboards.
* Error out when Solenid pin is not defined
Instead of defaulting to a (literally) random pin, error out instead. Because this pin may be used, or because that pin may not be exposed, or may not exist.
* Remove 'SOLENOID_ACTIVE' setting since it's not used
* Update documentation
* adding new pcb with default keymap and personal keymap
* Update keyboards/leeku/finger65/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Change to newer DEBOUNCE format
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* switch to pragma
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* remove unused define keyboards/leeku/finger65/config.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* some cleanup after debounce and other changes
* Remove no_suspend_power_down from keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* move to newer format and remove unused stuff
* ensure default has no leds for now
* change default layout name
* clean up the keymap a bit
* want grave not tilde
* a minor change and cleanup
* more stuff removed cause I don't care for LEDs
* remove some remaining stuff
* add RGBLED stuff
* Update keyboards/leeku/finger65/usbconfig.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/usbconfig.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/usbconfig.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/usbconfig.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* update USB information
* Update keyboards/leeku/finger65/usbconfig.h
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/keymaps/default/keymap.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/keymaps/default/keymap.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/keymaps/madhatter/keymap.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/keymaps/madhatter/keymap.c
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* cleanup and conform to existing standard
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* remove stuff that doesn't work
* add a JSON for the QMK configurator
* list the layouts only available
* let's just make it the 65 ansi layout with split backspace, eh?
* remove extra space
* Update keyboards/leeku/finger65/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/leeku/finger65/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* update readme
* remove redundant title
* Monica Bellucci ruined my life
* I'm having a RELIGIOUS EXPERIENCE ... and I don't take any DRUGS
* Update keyboards/leeku/finger65/rules.mk
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* add a URL to the username
* fix readme and make it simpler with links this time
* Update keyboards/leeku/finger65/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* Update keyboards/leeku/finger65/readme.md
Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>
* incorporate suggested changes
* update usb stuff for some stuff coming in the future
* update layout for LAYOUT_ALL
* USB power changes
* Move Ergodox EZ RGB code to custom driver
Also implements full addressing of Ergodox EZ's LED Strip, as written by seebs
Co-authored-by: Seebs <seebs@seebs.net>
* Make Clipping range accessible for custom drivers
* Remove RGBW_BB_TWI from driver and docs
* Revert changes to clipping range support
* Use just rgblight_set instead of full custom driver
* Convert to i2c_master commands
* Rename rgblight driver and clean up includes
* initial commit
* add pins and matrix
* add an appropriate keymap
* set bootloader to caterina
* add QMK Configurator support
* turn on RGB and link time optimization
* add rgb pin
* update readme on rgb underglow info
* Update keyboards/tg4x/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/tg4x/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* Update keyboards/tg4x/readme.md
Co-Authored-By: fauxpark <fauxpark@gmail.com>
* setting product id to 1 to match original code
* Add initial pass at KLE convert
* Add cli log on convert
* Move kle2xy, add absolute filepath arg support
* Add overwrite flag, and context sensitive conversion
* Update docs/cli.md
* Fix converter.py typo
* Add convert unit test
* Rename to kle2qmk
* Rename subcommand
* Rename subcommand to kle2json
* Change tests to cover rename
* Rename in __init__.py
* Update CLI docs with new subcommand name
* Fix from suggestions in PR #6898
* Help with cases of case sensitivity
* Update cli.md
* Use angle brackets to indicate required option
* Make the output text more accurate
@ -15,7 +15,7 @@ QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains Q
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is [fork the repo through Github](https://github.com/qmk/qmk_firmware#fork-destination-box), and clone your repo locally to make your changes, push them, then open a [Pull Request](https://github.com/qmk/qmk_firmware/pulls) from your fork.
Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), or clone it via git (`git@github.com:qmk/qmk_firmware.git`), or https (`https://github.com/qmk/qmk_firmware.git`).
Otherwise, you can clone it directly with `git clone https://github.com/qmk/qmk_firmware`. Do not download the zip or tar files; a git repository is required to download the submodules in order to compile.
QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](feature_encoders.md).
This driver is currently AVR-only. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V).
## Usage
To use this driver, add the following to your `rules.mk`:
<sup>\* The ATmega328P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration.md).
@ -135,6 +159,28 @@ Creates a keymap.c from a QMK Configurator export.
qmk json-keymap [-o OUTPUT] filename
```
## `qmk kle2json`
This command allows you to convert from raw KLE data to QMK Configurator JSON. It accepts either an absolute file path, or a file name in the current directory. By default it will not overwrite `info.json` if it is already present. Use the `-f` or `--force` flag to overwrite.
**Usage**:
```
qmk kle2json [-f] <filename>
```
**Examples**:
```
$ qmk kle2json kle.txt
☒ File info.json already exists, use -f or --force to overwrite.
```
```
$ qmk kle2json -f kle.txt -f
Ψ Wrote out to info.json
```
## `qmk list-keyboards`
This command lists all the keyboards currently defined in `qmk_firmware`
@ -173,3 +173,35 @@ You will only be able to access these arguments using `cli.args`. For example:
```
cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.output)
```
# Testing, and Linting, and Formatting (oh my!)
We use nose2, flake8, and yapf to test, lint, and format code. You can use the `pytest` and `pyformat` subcommands to run these tests:
### Testing and Linting
qmk pytest
### Formatting
qmk pyformat
## Formatting Details
We use [yapf](https://github.com/google/yapf) to automatically format code. Our configuration is in the `[yapf]` section of `setup.cfg`.
?> Tip- Many editors can use yapf as a plugin to automatically format code as you type.
## Testing Details
Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and integration tests in this directory. We hope you will write both unit and integration tests for your code, but if you do not please favor integration tests.
If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
## Linting Details
We use flake8 to lint our code. Your code should pass flake8 before you open a PR. This will be checked when you run `qmk pytest` and by CI when you submit a PR.
@ -14,7 +14,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
* Think of them as a story describing the feature
* Use them liberally to explain why particular decisions were made.
* Do not write obvious comments
* If you not sure if a comment is obvious, go ahead and include it.
* If you're not sure if a comment is obvious, go ahead and include it.
* In general we don't wrap lines, they can be as long as needed. If you do choose to wrap lines please do not wrap any wider than 76 columns.
* We use `#pragma once` at the start of header files rather than old-style include guards (`#ifndef THIS_FILE_H`, `#define THIS_FILE_H`, ..., `#endif`)
* We accept both forms of preprocessor if's: `#ifdef DEFINED` and `#if defined(DEFINED)`
Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the `qmk_firmware/` folder:
./bin/qmk docs
or if you only have Python 3 installed:
python3 -m http.server 8936
and navigating to `http://localhost:8936/`.
## Keymaps
Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap.
@ -114,7 +114,15 @@ Two more deprecated functions exist that provide the LED state as a `uint8_t`:
This function will be called when the state of one of those 5 LEDs changes. It receives the LED state as a struct parameter.
You must return either `true` or `false` from this function, depending on whether you want to override the keyboard-level implementation.
By convention, return `true` from `led_update_user()` to get the `led_update_kb()` hook to run its code, and
return `false` when you would prefer not to run the code in `led_update_kb()`.
Some examples include:
- overriding the LEDs to use them for something else like layer indication
- return `false` because you do not want the `_kb()` function to run, as it would override your layer behavior.
- play a sound when an LED turns on or off.
- return `true` because you want the `_kb` function to run, and this is in addition to the default LED behavior.
?> Because the `led_set_*` functions return `void` instead of `bool`, they do not allow for overriding the keyboard LED control, and thus it's recommended to use `led_update_*` instead.
@ -122,66 +130,41 @@ You must return either `true` or `false` from this function, depending on whethe
```c
bool led_update_kb(led_t led_state) {
if(led_update_user(led_state)) {
if (led_state.num_lock) {
writePinLow(B0);
} else {
writePinHigh(B0);
}
if (led_state.caps_lock) {
writePinLow(B1);
} else {
writePinHigh(B1);
}
if (led_state.scroll_lock) {
writePinLow(B2);
} else {
writePinHigh(B2);
}
if (led_state.compose) {
writePinLow(B3);
} else {
writePinHigh(B3);
}
if (led_state.kana) {
writePinLow(B4);
} else {
writePinHigh(B4);
}
return true;
bool res = led_update_user(led_state);
if(res) {
// writePin sets the pin high for 1 and low for 0.
// In this example the pins are inverted, setting
// it low/0 turns it on, and high/1 turns the LED off.
// This behavior depends on whether the LED is between the pin
// and VCC or the pin and GND.
writePin(B0, !led_state.num_lock);
writePin(B1, !led_state.caps_lock);
writePin(B2, !led_state.scroll_lock);
writePin(B3, !led_state.compose);
writePin(B4, !led_state.kana);
}
return res;
}
```
### Example `led_update_user()` Implementation
This incomplete example would play a sound if Caps Lock is turned on or off. It returns `true`, because you also want the LEDs to maintain their state.
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EEP_RST` keycode or [Bootmagic](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
```c
void eeconfig_init_user(void) { // EEPROM is getting reset!
void eeconfig_init_user(void) { // EEPROM is getting reset!
user_config.raw = 0;
user_config.rgb_layer_change = true; // We want this enabled by default
eeconfig_update_user(user_config.raw); // Write default value to EEPROM now
@ -508,7 +491,7 @@ The `val` is the value of the data that you want to write to EEPROM. And the `e
By default, the tapping term is defined globally, and is not configurable by key. For most users, this is perfectly fine. But in come cases, dual function keys would be greatly improved by different timeouts than `LT` keys, or because some keys may be easier to hold than others. Instead of using custom key codes for each, this allows for per key configurable `TAPPING_TERM`.
To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first.
To enable this functionality, you need to add `#define TAPPING_TERM_PER_KEY` to your `config.h`, first.
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.
## Bezugsquelle für QMK
Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf Github](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
Ansonsten kannst Du es als [zip](https://github.com/qmk/qmk_firmware/zipball/master) oder [tar](https://github.com/qmk/qmk_firmware/tarball/master) herunterladen, oder es direkt via git klonen (`git clone git@github.com:qmk/qmk_firmware.git` bzw. `git clone https://github.com/qmk/qmk_firmware.git`).
## Anleitung fürs Kompilieren
Bevor Du in der Lage bist, die Firmware zu kompilieren, musst Du eine [Entwicklungsumgebung](de/getting_started_build_tools.md) für AVR und/oder ARM aufsetzen. Danach kannst Du mit dem `make` Befehl eine Keymap für deine Tastatur erzeugen. Die Notation dafür ist:
make planck/rev4:default
Dies generiert die Revision `rev4` für eine Tastatur vom Type `planck` mit der `default` Tastaturbelegung. Nicht alle Tastaturen haben Revisionen (auch bekannt als Subprojekt oder Unterordner) weswegen dies auch ausgelassen werden kann:
make preonic:default
## Möglichkeiten der Anpassung
QMK hat viele [Features](de/features.md), die es zu entdecken gibt. In der [Dokumentation](https://docs.qmk.fmk) kannst Du Dir einen Überblick verschaffen. Die meisten Features basieren darauf, die [Tastaturbelegung](de/keymap.md) anzupassen und das Verhalten der [Keycodes](de/keycodes.md) zu verändern.
QMK erscheint für den Host als normales HID Eingabegerät und benötigt deshalb keine zusätzlichen Treiber. Der Bootloader, den Du für das Flashen der Firmware benötigst, jedoch meistens schon.
Hierzu gibt es zwei Ausnahmen: den Caterina Bootloader, meistens auf Pro Micros, sowie den HalfKay Bootloader auf PJRC Teensys. Diese erscheinen als serieller Port und als generisches HID Gerät und benötigen keine Treiber.
Wir empfehlen deshalb [Zadig](https://zadig.akeo.ie/). Wenn Du die Entwicklungsumgebung mit MSYS2 oder WSL installiert hast, wird dich dass `qmk_install.sh` Skript gefragt haben, ob es die Treiber für dich installieren sollte.
## Installation
Versetze deine Tastatur in den Bootloader-Modus, entweder durch Betätigung des physischen `RESET` Schalters - meist auf der Unterseite der Platine - oder durch das Auslösen des Key-Codes `RESET` bzw. `KC_RESET` (sollte in der zur Tastatur gehörigen `keycode.c` zu entnehmen sein). Sollte deine Tastatur weder noch besitzen, versuche es damit die `Escape`-Taste oder `Leertaste + B` zu halten während Du die Tastatur mit dem PC verbindest (Siehe auch [Bootmagic](de/feature_bootmagic.md) für weitere Details). Ein paar Tastaturen benutzen das [Command](de/feature_command.md)-Feature an Stelle von Bootmagic; in diesem Fall kannst du mit den Tastenkombinationen `linkes Shift + rechtes Shift + B` oder `linkes Shift + rechtes Shift + Escape` zu jeder Zeit in den Bootloader wechseln solange die Tastatur verbunden ist.
Eingie Tastaturen haben u.U. spezielle Anweisungen um in den Bootloader-Modus zu gelangen. Zum Beispiel kann die [Bootmagic-Lite](de/feature_bootmagic.md#bootmagic-lite)-Taste (default: Escape) auf eine andere Taste gemappt sein; oder die magische Kombination (default: linkes Shift+rechtes Shift) verwendet anstatt Shift die STRG-Tasten. Die zur Tastatur gehörige README sollte dir Aufschluss darüber geben wie der Bootloader-Modus ausgelöst werden kann wenn Du unsicher bist.
Um ein Gerät mit USBaspLoader in den Bootloader-Modus zu versetzen, halte `BOOT` gedrückt während Du den `RESET`-Knopf drückst.
Alternativ, halte `BOOT` gedrückt während Du das USB-Kabel einsteckst.
Zadig sollte das Bootloader-Gerät automatisch erkennen. Manchmal musst Du zusätzlich noch **Options → List All Devices** auswählen.
- Tastaturen mit Atmel AVR MCUs sollten als `ATm32U4DFU` (oder ähnlich) angezeigt werden, mit der Vendor ID `03EB`.
- USBasp werden als `USBasp` angezeigt, mit VID/PID `16C0:05DC`.
- Tastaturen AVR controller und dem QMK-DFU Bootloader haben den namen `<Tastatur Name> Bootloader` und die VID `03EB`.
- Die meisten ARM Tastaturen werden als `STM32 BOOTLOADER` angezeigt, mit VID/PID `0483:DF11`.
!> Sollte Zadig ein oder mehrere Geräte mit `HidUsb`-Treiber anzeigen, dann ist deine Tastatur wahrscheinlich nicht im Bootloader-Modus. Der Pfeil wird orange eingefärbt sein und Du wirst nach einer Bestätigung gefragt um Veränderungen am System vorzunehmen. In diesem Fall **fahre nicht fort**!
Wenn der Pfeil grün angezeigt wird, wähle den Treiber aus und klicke auf **Treiber installieren**. Der `libusb-win32`-Treiber sollte gewöhnlich für AVR verwendet werden und `WinUSB` für ARM. Sollte es danach noch nicht möglich sein die Tastatur zu flashen, versuche es mit einem anderen Treiber. Für USBaspLoader Geräte, die über die Befehlszeile mit MSYS2 geflasht werden, wird der `libusbk`-Treiber empfohlen. Ansonsten sollte `libusb-win32` funktionieren wenn die QMK Toolbox verwendet wird.
![Zadig mit Bootloader-Treiber korrekt installiert](https://i.imgur.com/b8VgXzx.png)
Entferne nun deine Tastatur und verbinde sie erneut um sicherzugehen dass der neue Treiber erfolgreich installiert wurde. Wenn Du QMK Toolbox benutzt, starte die Anwendung zur Sicherheit einmal neu, da Veränderungen am Treiber manchmal nicht richtig erkannt werden. Wenn dies immer noch nicht erfolgreich war hilft es an dieser Stelle manchmal ein Neustart des Computers.
## Wiederherstellung einer Installation für ein falsches Gerät
Wenn Du feststellst dass Du anschließend auf deiner Tastatur nicht mehr tippen kannst, ist etwas bei der Installation schief gelaufen. Ein häufiger Fehler ist es dass die Tastatur nicht im Bootloader-Modus war und stattdessen der Treiber für das HID-Gerät ersetzt wurde. Dies kannst Du einfach mit Zadig überprüfen, eine funktionierende Tastatur verwendet als Treiber `HidUsb` auf allen Interfaces .
![Eine funktionierende Tastatur aus Zadigs Sicht](https://i.imgur.com/Hx0E5kC.png)
Öffne den Geräte-Manager und suche nach einem Gerät das wie deine Tastatur aussieht.
![Die Tastatur mit dem falschen Treiber installiert, im Geräte-Manager](https://i.imgur.com/L3wvX8f.png)
Rechtsklick und **Gerät deinstallieren** anklicken. Bitte gehe sicher dass in diesem Schritt auch **Treibersoftware für dieses Gerät löschen** markiert ist.
![Der "Gerät deinstallieren"-Dialog, mit "Treibersoftware für dieses Gerät entfernen" markiert](https://i.imgur.com/aEs2RuA.png)
Klick **Aktion → Suche nach veränderter Hardware**. Nun solltest Du wieder in der Lage sein normal zu tippen. Vergewissere dich mit Hilfe von Zadig dass die Tastatur nun `HidUsb` als Treiber verwendet. Wenn dies der Fall ist sollte wieder alles funktionieren.
QMK ist eine mächtige Open Source Firmware für mechanische Tastaturen. Mit QMK kannst Du deine Tastatur sowohl sehr einfach als auch sehr umfangreich anpassen. Menschen unterschiedlichen Wissensstandes - vom kompletten Anfänger bis zum erfahrenen Programmierer - haben ihre Tastaturen mit QMK erfolgreich auf ihre persönlichen Bedürfnisse angepasst. Diese Anleitung soll Dir unabhängig von deinen Vorkenntnissen dabei helfen dies ebenfalls zu bewältigen.
Bist Du unsicher ob deine Tastatur QMK unterstützt? Wenn es eine mechanische Tastatur ist, die Du selbst gebaut hast, stehen deine Chancen gut. Wir unterstützen eine [Vielzahl](https://qmk.fm/keyboards/) selbst gebauter Tastaturen, sodass selbst wenn deine jetzige Tastatur nicht unterstützt wird Du keine Probleme haben solltest eine für deine Anforderungen zu finden.
## Übersicht
Diese Anleitung ist in 7 Abschnitte unterteilt:
* [Die ersten Schritte](newbs_getting_started.md)
* [Die erste Firmware auf der Kommandozeile erzeugen](newbs_building_firmware.md)
* [Die erste Firmware mit der Online GUI erzeugen](newbs_building_firmware_configurator.md)
* [Firmware flashen](newbs_flashing.md)
* [Testen und Debuggen](newbs_testing_debugging.md)
* [Git Leitfaden](newbs_best_practices.md)
* [Weitere hilfreiche Ressourcen für Anfänger](newbs_learn_more_resources.md)
Diese Anleitung richtet sich an Personen, die vorher noch nie Software kompiliert haben. Die Entscheidungen und Empfehlungen basieren auf dieser Grundannahme. Es gibt unterschiedliche Herangehensweisen für viele der Prozeduren und wir unterstützen die meisten Alternativen. Wenn Du mal nicht weiter weißt oder Dir nicht sicher bist, wie Du an ein Problem herangehen sollst, kannst Du uns gerne [um Hilfe bitten](getting_started_getting_help.md).
## Weitere Ressourcen
* [Thomas Baart's QMK Basics Blog](https://thomasbaart.nl/category/mechanical-keyboards/firmware/qmk/qmk-basics/) – Ein äußerst hilfreicher Blog eines Community-Mitglieds, der einige Grundlagen der QMK-Firmware aus der Sicht des Benutzers erklärt (auf Englisch).
Nachdem Du nun eine funktionierende Entwicklungsumgebung aufgesetzt hast, bist Du nun bereit, deine eigene Firmware zu erstellen. Dieses Sektion des Guides wird zwischen drei Programmen hin- und herwechseln: deinem Dateimanager, deinem Texteditor und der Befehlszeile. Lasse diese drei Fenster geöffnet, bis Du fertig und zufrieden mit deiner Tastatur-Firmware bist.
Solltest Du die Befehlszeile zwischenzeitlich geschlossen haben, vergiss nicht wieder in das richtige Verzeichnis zu navigieren, benutze dazu den Befehl `cd qmk_firmware`.
## Navigiere in deinen Keymap Ordner
Beginne damit, in das `keymaps` Verzeichnis für deine Tastatur zu navigieren.
Wenn Du macOS oder Windows benutzt, kannst Du einfach in das keymaps Verzeichnis wechseln.
?> macOS:<br>
open keyboards/<keyboard_folder>/keymaps
?> Windows:<br>
start .\\keyboards\\<keyboard_folder>\\keymaps
## Eine Kopie der `default` Tastaturbelegung erstellen
Wenn Du den `keymaps` Ordner geöffnet hast, solltest Du zuerst eine Kopie des `default` Verzeichnisses erstellen. Wir empfehlen dafür deinen GitHub Benutzernamen zu verweden, aber Du kannst auch jeden anderen Namen verwenden solange er nur aus Kleinbuchstaben, Zahlen und Unterstrichen besteht.
Um den Prozess zu automatisieren kannst Du dazu auch das Skript `new_keymap.sh` verwenden.
Navigiere dazu in das `qmk_firmware/util` Verzeichnis und gib folgenden Befehl ein:
```
./new_keymap.sh <keyboardpath><username>
```
Um zum Beispiel den Benutzernamen John für die Tastaturbelegung eines 1up60hse zu verwenden, würdest Du Folgendes eingeben:
```
./new_keymap.sh 1upkeyboards/1up60hse john
```
## Öffne `keymap.c` in deinem bevorzugtem Text Editor
Öffne deine `keymap.c`. In dieser Datei findest Du die Strukturen, die das Verhalten deiner Tastatur bestimmen. Oben in der `keymap.c` befinden sich Definitionen (defines) und Aufzählungen (enums), die die Tastaturbelegung leserlicher machen sollen. Weiter unten wirst Du eine Zeile finden, die wie folgt aussieht:
Diese Zeile markiert den Anfang der Liste der Ebenen (Layers). Darunter befinden sich Zeilen die entweder `LAYOUT` oder `KEYMAP` enthalten, das deutet auf den Start einer Ebene hin. Danach folgt eine Liste von Tasten, die dieser Ebene zugewiesen sind.
!> Beim Bearbeiten einer Tastaturbelegung solltest Du darauf achten, keine Kommata hinzuzufügen oder zu entfernen. Ansonsten kann dies dazu führen, dass deine Firmware nicht mehr kompiliert und es ist nicht immer einfach festzustellen, wo genau ein Komma zuviel oder zu wenig ist. Die letzte Zeile hat am Ende kein Komma, die Zeilen davor jedoch schon.
## Personalisiere die Tastaturbelegung nach deinen Wünschen
Wie Du diesen Schritt abschließt ist vollkommen Dir überlassen. Ändere die eine Sache die Dich stört oder verändere alles von Grund auf. Du kannst Ebenen entfernen die Du nicht brauchst oder Neue hinzufügen, bis zu 32 Stück. Die folgende Dokumentation verrät Dir was Du hier alles definieren kannst:
* [Keycodes](de/keycodes.md)
* [Features](de/features.md)
* [FAQ](de/faq.md)
?> Während Du langsam ein Gefühl dafür kriegst wie Keymaps funktionieren, solltest Du darauf achten nicht zuviel auf einmal zu verändern. Größere Änderungen machen es schwieriger, Probleme zu debuggen.
## Deine Firmware erzeugen
Wenn Du damit fertig bist, deine Tastaturbelegung anzupassen, musst Du noch die Firmware erzeugen. Öffne dazu wieder die Befehlszeile und führe folgenden Befehl aus:
make <my_keyboard>:<my_keymap>
Wenn deine Tastaturbelegung z.B. "xyverz" heißt und Du die Belegung für ein rev5 planck erzeugen möchtest, lautet der Befehl:
make planck/rev5:xyverz
Während des Kompiliervorgangs wird viel Text auf dem Bildschirm ausgegeben. Es sollte am Ende mit etwas enden das ungefähr so aussieht:
```
Linking: .build/planck_rev5_xyverz.elf [OK]
Creating load file for flashing: .build/planck_rev5_xyverz.hex [OK]
Copying planck_rev5_xyverz.hex to qmk_firmware folder [OK]
Checking file size of planck_rev5_xyverz.hex [OK]
* File size is fine - 18392/28672
```
## Deine Firmware flashen
Bitte fahre mit [Firmware flashen](de/newbs_flashing.md) fort, um zu erfahren, wie Du deine neue Firmware auf deine Tastatur flashen kannst.
Genau wie in einem Computer befindet sich auch in einer Tastatur ein Prozessor.
Dieser Prozessor führt Software aus, die registriert wenn Tasten gedrückt bzw. wieder losgelassen werden und leitet die entsprechenden Signale an den Computer weiter.
QMK übernimmt die Rolle dieser Software und teilt dem Host-Computer den aktuellen Zustand der Tastatur mit. Wenn Du eine Tastaturbelegung definierst, ist dies äquivalent zu einem ausführbarem Programm, das auf deiner Tastatur läuft.
QMK möchte seine BenutzerInnen in die Lage versetzen, simple Aufgaben möglichst einfach zu gestalten und gleichzeitig komplexe Dinge zu ermöglichen, die mit normalen Tastaturen ohne zusätzliche Software undenkbar wären. Du musst nicht programmieren können, um abgefahrene Tastaturbelegungen zu gestalten - es reicht wenn Du eine Idee hast und ein paar einfache syntaktische Regeln verstehen kannst.
# Los geht's!
Bevor Du damit loslegen kannst, deine Tastaturbelegung zu erstellen, musst Du ein wenig Software installieren und Dir eine Entwicklungsumgebung aufsetzen. Die gute Nachricht ist, dass das nur einmal erledigt werden muss, egal für wie viele verschiedene Tastaturen Du hinterher Firmware entwickeln willst.
Wenn Du es vorziehst mit einer grafischen Oberfläche zu entwickeln kannst Du auch dazu gerne direkt mit dem online [QMK Konfigurator](https://config.qmk.fm) loslegen. Siehe auch: [Firmware mit der Online GUI erzeugen](de/newbs_building_firmware_configurator.md)
## Software herunterladen
### Text Editor
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/).
?> 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).
### QMK Toolbox
QMK Toolbox ist ein optionales grafisches Programm für Windows und macOS, das es erleichtern soll, deine Tastatur zu programmieren und zu debuggen. Du wirst es höchstwahrscheinlich früher oder später als unverzichtbar ansehen, wenn es darum geht eine Tastatur einfach zu flashen oder zu debuggen, da es ermöglicht, sich debug-Nachrichten direkt anzeigen zu lassen.
[Hier kannst Du die aktuelle Version herunterladen.](https://github.com/qmk/qmk_toolbox/releases/latest)
* Für Windows: `qmk_toolbox.exe` (portable) oder `qmk_toolbox_install.exe` (installer)
* Für macOS: `QMK.Toolbox.app.zip` (portable) oder `QMK.Toolbox.pkg` (installer)
## Die Entwicklungsumgebung aufsetzen
Wir haben versucht, die Installation der Entwicklungsumgebung für QMK so einfach wie möglich zu gestalten. Alles, was Du tun musst, ist eine Linux oder Unix Umgebung aufzusetzen, danach macht QMK den Rest.
?> Wenn Du das erste Mal mit der Linux/Unix Befehlszeile arbeitest, schadet es nicht, sich mit ein paar Grundlagen und Befehlen vertraut zu machen. Diese Ressourcen sollten ausreichen, um sich das Nötigste anzueignen um mit QMK arbeiten zu können:<br>
[Erforderliche Linux Grundlagen](https://www.guru99.com/must-know-linux-commands.html)<br>
[Noch ein paar Linux Befehle](https://www.tjhsst.edu/~dhyatt/superap/unixcmd.html)
### Windows
Du wirst MSYS2 (o.Ä.) und Git benötigen.
* Befolge die Installationsanleitung auf der [MSYS2 Homepage](http://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`
### macOS
Du wirst Homebrew benötigen. Folge dafür den Anweisungen auf der [Homebrew homepage](https://brew.sh).
Nachdem Homebrew erfolgreich installiert ist, kannst Du mit _QMK aufsetzen_ fortfahren.
### Linux
Du benötigst Git, aber es ist ziemlich wahrscheinlich, dass es bereits installiert ist. Sollte dies nicht der Fall sein, kannst Du es mit dem folgenden Aufruf installieren:
* Debian / Ubuntu / Devuan: `apt-get install git`
* Fedora / Red Hat / CentOS: `yum install git`
* Arch Linux: `pacman -S git`
?> Docker ist ebenfalls eine Option für alle Plattformen. [Hier](de/getting_started_build_tools.md#docker) kannst Du dazu weitere Informationen finden.
## QMK aufsetzen
Wenn Du damit fertig bist, deine Linux/Unix Umgebung zu installieren, kannst Du damit fortfahren QMK herunterzuladen. Dafür werden wir mit Git das QMK Repository "klonen". Öffne ein Terminal oder ein MSYS2 MinGW Fenster, dies wirst Du für den Rest der Anleitung benötigen. In diesem Fenster rufst Du nun die beiden folgenden Kommandos auf:
?> Wenn Du bereits weißt, [wie man GitHub benutzt](de/getting_started_github.md), empfehlen wir, dass Du Dir ein eigenen Fork erstellst. Wenn Du nicht weißt, was das bedeuten soll, kannst Du diesen Ratschlag getrost ignorieren.
QMK liefert ein Script mit, das helfen soll, Dir alles Weitere abzunehmen. Du kannst es mit dem folgenden Befehl aufrufen:
util/qmk_install.sh
## Die Build-Umgebung testen
Nun sollte hoffentlich alles Nötige für eine funktionierende QMK Build-Umgebung installiert sein und Du solltest in der Lage sein, die QMK-Firmware zu kompilieren. Um dies mit einer `default` Tastaturbelegung zu testen, kannst Du den folgenden Befehl ausprobieren:
make <keyboard>:default
Der Befehl um z.B. die Firmware für ein _Clueboard 66%_ zu erzeugen lautet:
make clueboard/66/rev3:default
Wenn es fertig ist, sollte der Output ungefähr so ähnlich wie das Folgende aussehen:
Creating load file for flashing: .build/clueboard_66_rev3_default.hex [OK]
Copying clueboard_66_rev3_default.hex to qmk_firmware folder [OK]
Checking file size of clueboard_66_rev3_default.hex [OK]
* The firmware size is fine - 26356/28672 (2316 bytes free)
```
# Eine eigene Tastaturbelegung erstellen
Du bist nun fertig mit dem Setup der Entwicklungsumgebung und solltest somit in der Lage sein, deine eigenen Tastaturbelegungen zu erstellen. Um fortzufahren, folge bitte der nächsten Anleitung unter [Die erste Firmware](de/newbs_building_firmware.md).
Diese weiterführenden Ressourcen sind darauf ausgerichtet, Neulingen der QMK Commmunity mehr Informationen und ein besseres Verständnis zu einzelnen Themen zu bieten.
Nachdem Du deine Tastatur mit deiner angepassten Firmware geflasht hast, ist es nun an der Zeit sie auszuprobieren. Mit ein bisschen Glück sollte alles ohne Probleme funktionieren, wenn dies nicht der Fall ist, soll dieses Dokument dir dabei helfen, herauszufinden wo das Problem liegt.
## Testen
Die Tastatur zu testen ist relativ selbsterklärend. Drücke jede der Tasten um dich zu versichern, dass der gesendete Keyode der ist, den du erwarten würdest. Dafür gibt es sogar ein paar Programme die helfen sollen, dass keine Taste ausgelassen wurde.
Anmerkung: Diese Programme werden weder von QMK bereitgestellt oder gutgeheißen.
* [Switch Hitter](https://elitekeyboards.com/switchhitter.php) (Nur für Windows)
* [Keyboard Viewer](https://www.imore.com/how-use-keyboard-viewer-your-mac) (Nur für Mac)
Deine Tastatur wird Debug Informationen liefern wenn Du `CONSOLE_ENABLE = yes` in deiner `rules.mk` gesetzt hast. Die default-Ausgabe ist sehr beschränkt und kann wenn nötig durch die Aktivierung des Debug-Modes erhöht werden. Benutze dafür entweder den `DEBUG` Keycode in deiner Tastaturbelegung, das [Command](de/feature_command.md)-Feature oder füge den folgenden Code zu deiner Tastaturbelegung hinzu.
```c
void keyboard_post_init_user(void) {
// Customise these values to desired behaviour
debug_enable=true;
debug_matrix=true;
//debug_keyboard=true;
//debug_mouse=true;
}
```
### Debuggen mit der QMK Toolbox
Für kompatible Plattformen kann die [QMK Toolbox](https://github.com/qmk/qmk_toolbox) benutzt werden um Debug-Nachrichten deiner Tastatur anzuzeigen.
### Debuggen mit hid_listen
Bevorzugst Du es lieber auf der Befehlszeile zu debuggen? Dafür eignet sich das Programm [hid_listen](https://www.pjrc.com/teensy/hid_listen.html) von PJRC. Binaries sind für Windows, Linux und MacOS verfügbar.
<!-- FIXME: Describe the debugging messages here. -->
## Eigene Debug-Nachrichten senden
Manchmal ist es hilfreich Debug-Nachrichten innerhalb deines eigenen [Custom Codes](de/custom_quantum_functions.md) zu drucken. Das ist ziemlich einfach. Beginne damit `print.h` am Anfang deiner Datei zu inkludieren:
#include<print.h>
Danach stehen dir verschiedene Druck-Funktionen zur Verfügung:
* `print("string")`: Druckt einen simplen String
* `uprintf("%s string", var)`: Druckt einen formatierten String
* `dprint("string")` Druckt einen simplen String, aber nur wenn der Debug-Mode aktiviert ist
* `dprintf("%s string", var)`: Druckt einen formatierten String, aber nur wenn der Debug-Mode aktiviert ist
## Debug Beispiele
Anbei findest Du eine Sammlung von hilfreichen Beispielen. Für weitere Informationen Informationen sei an dieser Stelle auf [Debugging/Troubleshooting QMK](de/faq_debug.md) verwiesen.
### Which matrix position is this keypress?
### Welche Matrix Position hat dieser Tastenanschlag
Beim Portieren, oder bei der Fehlerdiagnose von PCB Problemen, ist es nützlich sich anzeigen zu lassen ob ein Tastenanschlag richtig erkannt wurde. Um die Protokollierung für diesen Fall zu aktivieren, füge bitte folgenden Code zu deiner Tastaturbelegung `keymap.c` hinzu.
### Wieviel Zeit wurde benötigt um einen Tastenanschlag zu detektieren?
Wenn Performance-Probleme auftreten ist es hilfreich die Frequenz, mit der die Matrix gescannt wird, zu wissen. Um dies in diesem Fall zu aktiveren füge, den folgenden Code zu deiner Tastaturbelegung in `config.h` hinzu.
Make example for this keyboard (after setting up your build environment):
@ -38,5 +38,3 @@ Make example for this keyboard (after setting up your build environment):
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
```
There needs to be two spaces at the end of the `Keyboard Maintainer` and `Hardware Supported` lines for it to render correctly with Markdown.
@ -19,7 +19,7 @@ De cualquier manera, también puedes descargarlo directamente en formatos ([zip]
## Cómo compilar
Antes de poder compilar, necesitarás [instalar un entorno](getting_started_build_tools.md) para el desarrollo de AVR y/o ARM. Una vez hayas completado este paso, usarás el comando `make` para compilar un teclado y keymap con la siguiente notación:
Antes de poder compilar, necesitarás [instalar un entorno](es/getting_started_build_tools.md) para el desarrollo de AVR y/o ARM. Una vez hayas completado este paso, usarás el comando `make` para compilar un teclado y keymap con la siguiente notación:
make planck/rev4:default
@ -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](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](keymap.md), y cambiando los [keycodes](keycodes.md).
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).
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.