Co-authored-by: wilba <wilba@wilba.tech>
Co-authored-by: Pablo Martínez <58857054+elpekenin@users.noreply.github.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Replace Tapping Force Hold feature with Quick Tap Term
* Replace keyboard level TAPPING_FORCE_HOLD with QUICK_TAP_TERM 0
* Deprecate force hold in info_config.json
* Before and after quick tap term unit tests
* Quick tap unit tests iteration
* Keymap config.h correction
* Remove TAPPING_FORCE_HOLD_PER_KEY macros that were missed
* Add two more test cases for quick tap
* Replace TAPPING_FORCE_HOLD with QUICK_TAP_TERM in configs #2
* Replace TAPPING_FORCE_HOLD_PER_KEY with QUICK_TAP_TERM_PER_KEY in configs #2
* Add function declaration for get_quick_tap_term
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Make process_tapping more readable
Move most #ifdefs into conditionally defined macros to make the logic
easier to follow.
* Retain momentary layers until the end of tapping
This allows mod-tap and layer-tap keys on layers to behave as expected.
Bug: https://github.com/qmk/qmk_firmware/issues/17281
* Add tests for delayed mod/layer release while tapping
Mods and layer key release is delayed while tapping is in progress to
ensure that the tap is registered with the modifier state and on the
layer where the key was first pressed.
Signed-off-by: Felix Kuehling <felix.kuehling@gmail.com>
* Add macros to extract parameters from keycode values
Implement both encoding and decoding for keycodes like TO(layer) or
LM(layer, mod) in one place, so that the decoding won't get out of sync
with the encoding.
While at it, fix some macros for creating keycode values that did not
apply the appropriate masks to parameters (and therefore could allow the
result to be out of range if a wrong parameter was passed).
* keymap_common: Use extraction macros for keycodes
* pointing_device_auto_mouse: Use extraction macros for keycodes
Fixes#18970.
* process_autocorrect: Use extraction macros for keycodes
* process_caps_word: Use extraction macros for keycodes
(Also fix a minor bug - SH_TG was not handled properly)
* process_leader: Use extraction macros for keycodes
(Technically the code is not 100% correct, because it always assumes
that the LT() or MT() action was a tap, but it's a separate issue that
already existed before the keycode changes.)
* process_unicode: Use extraction macros for keycodes
* process_unicodemap: Use extraction macros for keycodes
* Deprecate SECURE_* keycodes for QK_SECURE_*
* Update keycode process
* Update process_secure.c
* Apply suggestions from code review
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Move Bluetooth-related function calls up to host/keyboard level
* Remove pointless set_output() call
* Move bluetooth (rn42) init to end of keyboard_init()
* Enable SPI/UART for ChibiOS targets
* Some more slight tweaks
* Add ARRAY_SIZE and CEILING utility macros
* Apply a coccinelle patch to use ARRAY_SIZE
* fix up some straggling items
* Fix 'make test:secure'
* Enhance ARRAY_SIZE macro to reject acting on pointers
The previous definition would not produce a diagnostic for
```
int *p;
size_t num_elem = ARRAY_SIZE(p)
```
but the new one will.
* explicitly get definition of ARRAY_SIZE
* Convert to ARRAY_SIZE when const is involved
The following spatch finds additional instances where the array is
const and the division is by the size of the type, not the size of
the first element:
```
@ rule5a using "empty.iso" @
type T;
const T[] E;
@@
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
@ rule6a using "empty.iso" @
type T;
const T[] E;
@@
- sizeof(E)/sizeof(T)
+ ARRAY_SIZE(E)
```
* New instances of ARRAY_SIZE added since initial spatch run
* Use `ARRAY_SIZE` in docs (found by grep)
* Manually use ARRAY_SIZE
hs_set is expected to be the same size as uint16_t, though it's made
of two 8-bit integers
* Just like char, sizeof(uint8_t) is guaranteed to be 1
This is at least true on any plausible system where qmk is actually used.
Per my understanding it's universally true, assuming that uint8_t exists:
https://stackoverflow.com/questions/48655310/can-i-assume-that-sizeofuint8-t-1
* Run qmk-format on core C files touched in this branch
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* Fix Caps Word to treat mod-taps more consistently.
Previously, holding any mod-tap key while Caps Word is active stops Caps
Word, and this happens regardless of `caps_word_press_user()`. Yet for
regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to
`caps_word_press_user()` to determine whether to continue, and
similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is
passed to `caps_word_press_user()` to determine whether to continue.
This commit makes held mod-tap keys consistent with regular mod keys:
* Holding a `RALT_T` mod-tap is ignored.
* When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to
`caps_word_press_user()` to determine whether to continue.
* When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is
passed to `caps_word_press_user()`.
Particularly, with this fix a user may choose to continue Caps Word when
a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in
`caps_word_press_user()`. For instance as
```
bool caps_word_press_user(uint16_t keycode) {
switch (keycode) {
// Keycodes that continue Caps Word, with shift applied.
case KC_A ... KC_Z:
case KC_MINS:
add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key.
return true;
// Keycodes that continue Caps Word, without shifting.
case KC_1 ... KC_0:
case KC_BSPC:
case KC_DEL:
case KC_UNDS:
case KC_LSFT: // <<< Added here.
case KC_RSFT:
return true;
default:
return false; // Deactivate Caps Word.
}
}
```
* Fix Caps Word to treat mod-taps more consistently.
Previously, holding any mod-tap key while Caps Word is active stops Caps
Word, and this happens regardless of `caps_word_press_user()`. Yet for
regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to
`caps_word_press_user()` to determine whether to continue, and
similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is
passed to `caps_word_press_user()` to determine whether to continue.
This commit makes held mod-tap keys consistent with regular mod keys:
* Holding a `RALT_T` mod-tap is ignored.
* When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to
`caps_word_press_user()` to determine whether to continue.
* When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is
passed to `caps_word_press_user()`.
Particularly, with this fix a user may choose to continue Caps Word when
a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in
`caps_word_press_user()`. For instance as
```
bool caps_word_press_user(uint16_t keycode) {
switch (keycode) {
// Keycodes that continue Caps Word, with shift applied.
case KC_A ... KC_Z:
case KC_MINS:
add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key.
return true;
// Keycodes that continue Caps Word, without shifting.
case KC_1 ... KC_0:
case KC_BSPC:
case KC_DEL:
case KC_UNDS:
case KC_LSFT: // <<< Added here.
case KC_RSFT:
return true;
default:
return false; // Deactivate Caps Word.
}
}
```
* Update quantum/process_keycode/process_caps_word.c
Co-authored-by: Joel Challis <git@zvecr.com>
Static x & y should be the same type as touchData.xValue &
touchData.yValue: uint16_t.
Their delta could be larger than int8_t and should be constrained to
mouse_xy_report_t.
Move Pointing Device Initialization to after Split Post Initialization
If both pointing device and split is enabled, the pointing device init needs to be called after the split post init, otherwise the connection (serial/etc) isn't initialized yet, and any commands that need to send data over (such as calling the set cpi command) never get sent over.
* PMW33XX drivers overhaul
This combines the PMW3389 and PM3360 drivers as they only differ in the
firmware blobs and CPI get and set functions. The following changes have
been made:
* PMW3389 now gets the same multi-sensor feature that is already available on the
PMW3360.
* Introduced a shared pmw33xx_report_t struct is now directly readable via SPI
transactions instead of individual byte-sized reads, saving multiple
copies and bitshift operations.
* pmw33(89/60)_get_report functions had unreachable branches in their motion
detection logic these have been simplied as much as possible.
* The fast firmware upload option has been removed as this becomes obsolete by
the newly introduced polled waiting functions for ChibiOS polled waiting
* PMW33(60/89)_SPI_LSBFIRST and PMW33(60/89)_SPI_MODE config options
have been removed as they don't need to be configurable.
* All PMW3389 and PMW3360 defines have been unified to a PMW33XX prefix
to reduce code duplication and make the defines interchangeable
* Adjust keyboards to PMW33XX naming scheme
* Add missing '(' to print_bin_reverse32 declaration
* Fix insufficient character buffers on satisfaction75
* Remove \0 character in format string and use corrected offset math
instead on rocketboard 16
* Replace snprintf_ with snprintf for djinn
* Explicitly ignore format checks for tracktyl manuform that uses %b
specifier
* Print properly escaped version string in command.c, as PRODUCT or
other defines can contain constructs like 'Vendor keyboard 66%' which
will be interpreted as a format specifier
mpaland printf implementation was abandoned in ~2019 and the fork by
eyalroz is now regarded to be the goto replacement of it. So this commit
incoporates the changes needed to use this fork in QMK.
Note that pointer ptrdiff_t is always supported since commit
51c90f93a97fdaef895783ecbe24569be0db7cb8
* Disable RESET keycode because of naming conflicts
* Add Pico SDK as submodule
* Add RP2040 build support to QMK
* Adjust USB endpoint structs for RP2040
* Add RP2040 bootloader and double-tap reset routine
* Add generic and pro micro RP2040 boards
* Add RP2040 onekey keyboard
* Add WS2812 PIO DMA enabled driver and documentation
Supports regular and open-drain output configuration. RP2040 GPIOs are
sadly not 5V tolerant, so this is a bit use-less or needs extra hardware
or you take the risk to fry your hardware.
* Adjust SIO Driver for RP2040
* Adjust I2C Driver for RP2040
* Adjust SPI Driver for RP2040
* Add PIO serial driver and documentation
* Add general RP2040 documentation
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
* Initial import of wear-leveling algorithm.
* Alignment.
* Docs tweaks.
* Lock/unlock.
* Update quantum/wear_leveling/wear_leveling_internal.h
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
* More tests, fix issue with consolidation when unlocked.
* More tests.
* Review comments.
* Add plumbing for FNV1a.
* Another test checking that checksum mismatch clears the cache.
* Check that the write log still gets played back.
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
