* Fix out-of-bounds read in encoder test initialisation
* Reject out-of-range tracks in sequencer track activation
* Compare unaligned flash word bytewise in emulated EEPROM test
* Abort on out-of-range access in the test platform EEPROM emulation
* Add SANITIZE=yes to the native unit test build
* Fix ChibiOS control OUT buffer sizing.
Some ChibiOS low level drivers (STM32 USBv1, WB32, Kinetis) write a whole control packet into the EP0 OUT buffer rather than only the requested length, so the buffer must hold a full packet. SET_REPORT and SET_LINE_CODING now share one packet-sized buffer, and line coding is copied out on transfer completion so a short data stage cannot leave it partly overwritten.
* Use exact size.
* Recover some RAM on failing builds.
With SPLIT_ACTIVITY_ENABLE the slave adopts the master's activity
timestamps, but applies timer syncs from its main loop, so its synced
clock can lag the master's by however long the loop was busy. A key
press can then carry a timestamp slightly ahead of the slave's clock,
and the unsigned elapsed time wraps to nearly UINT32_MAX, briefly
tripping RGB_MATRIX_TIMEOUT, LED_MATRIX_TIMEOUT and other idle checks.
Treat a timestamp up to one second in the future as no time elapsed.
Fixes#26544
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
rgblight_led_index() subtracts the clipping start position and returns a
uint8_t, so on the half whose clipping range does not start at 0 the LEDs
of the other half wrap around to indices like 252..255. Those reached
rgblight_driver.set_color() unchecked and, with the RP2040 vendor WS2812
driver, overwrote RAM past the LED buffer (the emulated EEPROM cache).
Skip indices outside the clipping range in setrgb() and route the direct
set_color() calls through it.
Fixes#26480
The mapping of CCW=VOLD, CW=VOLU was wrong in the original commit 13821fd,
but wasn't noticed because the pin mapping was _also_ wrong. The encoder
mapping was fixed in commit a73014f but that resulted in the encoder working
backwards. This commit corrects the pin mapping so that the encoder works as
expected.
* Add keyboard mini_mighty_kbd.
* Update keyboards/mini_mighty/kbd/keymaps/default/keymap.c
Co-authored-by: Jack Sangdahl <jack@pngu.org>
* Update keyboards/mini_mighty/kbd/keymaps/default/keymap.c
Co-authored-by: Jack Sangdahl <jack@pngu.org>
* Update keyboards/mini_mighty/kbd/keymaps/default/keymap.c
Co-authored-by: Jack Sangdahl <jack@pngu.org>
* Update keyboards/mini_mighty/kbd/keyboard.json
Co-authored-by: Jack Sangdahl <jack@pngu.org>
* Migrated features/build options from rules.mk to keyboard.json
* Update keyboards/mini_mighty/kbd/keymaps/default/keymap.c
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Added a new layout with swapped backspace and backslash as default. Renamed the old layout as "legacy".
* Removed the "legacy" layout as it's no longer needed. All shipped mini-mighty-kbd units use the default layout.
* Updated the readme build instructions to use QMK compile instead of make.
---------
Co-authored-by: Jack Sangdahl <jack@pngu.org>
Co-authored-by: Drashna Jaelre <drashna@live.com>
fix(os_detection): don't classify macOS sequences as Windows
macOS 26.x (ChibiOS) can send a late wLength=0x04 packet after the two
0xFF packets that already established OS_MACOS. The Windows check
(cnt_ff >= 2 && cnt_04 >= 1) fired on this combination and overwrites
the correct result.
Real-world Windows sequences always start with 0xFF packets (cnt_02 = 0);
macOS sequences always open with at least two 0x02 packets (cnt_02 >= 2).
Adding && setups_data.cnt_02 < 2 to the Windows condition is sufficient
to separate the two populations without affecting any existing detection.
Adds a regression test for the affected sequence.