* [Keymap] adding new user (p4yne) layout with complex lighting features (per layer, per key, per type) and usefull layers DE/US, etc.
Co-authored-by: Drashna Jaelre <drashna@live.com>
* SPLIT_USB_DETECT added.
* lednotg keymap added.
* lednotg missing modification fixed.
* VERSION is available.
* USER00 is used instead of SAFE_RANGE in via/keymap.c
* Working on new dactyl
* Preliminary build and keymap in place for 4x5_5 dactyl manuform
* Removing first attempt to use 4x5
* Updating to match c style guide
* Fixing issues after merge, deletion of dactyl_manuform.h
* Spliting out custom keymap
* Adding license headers
* Fixing EE_HANDS detection on Pro-Micro
The pro-micro was not working when I plugged into the elite-c on the
right hand side of my keyboard. Adding the SPLIT_USB_DIRECT definition
fixed the issue.
* Apply suggestions from code review
Adding Drashna's delete comments
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Removed config.h for keymaps and tweaked keymap
Per Drashna's pr review, I have removed the config.h files for the
keymaps.
Also tweaked my keymap to switch backspace and enter. Added tapping
toggle for RAISE.
* Further tweaking ssedrick keymap for dactyl_manuform 4x5_5
As with most new keyboards, they take some getting used to.
I've rearranged my thumb cluster to hopfully a more long
term solution.
* Adding missing KC_BSLS to ssedrick keymap for 4x5_5
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 46: Copy from 52 and file rename
* 46: File internals refer to 46, not 52
* 46: Board remove row
* 46: Keymap: Lshift becomes ctrl, Rshift a symbol
- ESC and CAPs on upper thumbs
- AltGr and App on upper thumbs
- Page up/down on upper thumbs
- F11, F12 and mods for them on adjust
* 46: Readme update for json script, tweaks
* 46: Board fix LED count
* 46: Keymap: Arrows right, symmetric layer keys
* 46: Readme: Image link with and w/o outer pinkie
* 46: Keymap: link fixed image of nav layer
* 46: Keymap: fix reaching adj layer
Co-authored-by: mmccoyd <mmccoyd@cs.berkley.edu>
* Fixed Left Shift tapdance in general and for gaming mode. (#12)
* update ISO readme
* left shift fixed in general, including for gaming mode
* fixed toggle menu rendering on ISO layouts
* updated readme's and cosmetics
* update readme's
* update readme's again
* readme cosmetics
* consolidate readme's
* more readme cosmetics
* clarification for bootloader mode on ISO
* Autocorrect added with 400 word English dictionary (#13)
* autocorrect added with 400 word dictionary
* update readme's for autocorrect
* Add FN-B as shortcut to bootloader
* Update .gitignore
Co-authored-by: Joel Challis <git@zvecr.com>
* RGB changes to system numlock and ISO extended alphas
- hide system numlock off indicator (primarily for Mac users) by moving it to numpad and FN layers instead
- give users with extended alpha ISO languages a config option to add RGB highlights for extras alphas on capslock
* readme updates
* Fixed [FN]B and [FN]N shortcuts not working on numpad layer
Co-authored-by: Joel Challis <git@zvecr.com>
* 52 Keymap.json: Set for Hillside 52
- Change script rows
* 52 Keymap.c: mirror .json
CAPSWORD, QK_BOOT, readme cleanup, EE_RST
* 52 Keymap.json: Initial files copy from 56
* 52 Keymap.json nav/edit lay, thumb shift, syms
- Del in backspace spot on sym layer
- Thumb shift OSM instead of extra space
- Nav/edit on num/fn: arrows cut copy paste undo redo, page up/down
- Fn keys bottom row to allow nav edit keys
- App and AltGr on lower row, on their layer
- Braces on index, so more common -= on middle ring.
- Adjust has Ctrl/GUI swap
- EE_RST, CAPSWORD, QK_BOOT, SPLIT_DETECT
* 52 Family: readme image and folder link
* 52 Board: initial copy from 56
* 52 Keymap via
* 52 Board: remove keys, cant columns, better ids
- .json: vid: MM, pid: H52
* 52 Keymap.c: initial.c copy from 48
* QK_BOOT EE_CLR, not ANY(), as config.qmk supports
- CAPSWRD instead of ANY, though config.qmk still converts to ANY()
* Cleanup readme
* 52 Keymap: Remove redundant key, cleanup script
* 52 Keymap: Fix template
* 52 Readme: Link lower res image better for readme
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52 Keymap: Move pretty-print script to GitHub wiki
* 52 Keymap: Link to 1024 res image thumbnails
* 52 Keymap: fix whitespace before image link
* Family: Fix image link to 1024 thumb
Co-authored-by: Drashna Jaelre <drashna@live.com>
* 52: Keymap: Caps word on a layer home row
* 52: Keymap: Arrows on right. Symmetric layer keys.
- Nav:
- Arrows on right so up/down more intuitive. Page up/down on ends
- Cut on home row, as more common
- Sym:
- Layer mods on activate hand, extras symbols on left
- Common digits on lower row
- Base:
- Layer keys symmetric, on most extended, not resting, thumb
- Mute on util key for easy use
- Swap layers 3 and 4 to match swapped thumbs
Co-authored-by: mmccoyd <mmccoyd@cs.berkley.edu>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Unfortunately, the crippled versions of “Bluepill” boards with
STM32F103C6xx chips instead of STM32F103C8xx are now sold all over the
place, sometimes advertised in a confusing way to make the difference
not noticeable until too late. Add minimal support for these MCUs in
the common “Bluepill with stm32duino” configuration, so that it could be
possible to make something useful from those boards (although fitting
QMK into the available 24 KiB of flash may be rather hard).
(In fact, I'm not sure whether the “STM32” part of the chip name is
actually correct for those boards of uncertain origin, so the onekey
board name is `bluepill_f103c6`; another reason for that name is to
match the existing `blackpill_f401` and `blackpill_f411`.)
The EEPROM emulation support is not included on purpose, because
enabling it without having a working firmware size check would be
irresponsible with such flash size (the chance that someone would build
a firmware where the EEPROM backing store ends up overlapping some
firmware code is really high). Other than that, enabling the EEPROM
emulation code is mostly trivial (the `wear_leveling` driver with the
`embedded_flash` backing store even works without any custom
configuration, although its code is significantly larger than the
`vendor` driver, which may also be important for such flash size).
