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.
This change does two things:
* Rounds up instead of down, so that a low count check isn't needed.
* When the matrix col is odd, by rounding up, and checking if the right
and left indices are the same, skip one since we don't need to process
the same column twice.
qp_lvgl_flush() called lv_disp_flush_ready() only inside the
`if (selected_display)` block. When LVGL invokes the flush callback while
selected_display is NULL, the callback returns without ever signalling
completion, so LVGL keeps the flush marked "in progress" and stalls all
further rendering.
Move lv_disp_flush_ready() out of the conditional so it is always called,
per LVGL's contract that every flush_cb must signal ready exactly once.
* Make the sequencer feature build again
SEQUENCER_ENABLE only set MUSIC_ENABLE, so -DSEQUENCER_ENABLE was never
defined and neither sequencer.c nor process_sequencer.c were compiled;
process_sequencer.c also lost the includes it depends on. Wire the make
target up like the other features and add the missing includes.
* Include sequencer.h in keyboard.c for sequencer_task()
* Update builddefs/common_features.mk
Co-authored-by: Joel Challis <git@zvecr.com>
---------
Co-authored-by: Joel Challis <git@zvecr.com>
cancel_key_lock() called UNSET_KEY_STATE(0x0), which expands to clearing
only bit 0 of key_state[0]. The lock state is a 256-bit map spread across
key_state[0..3], so every locked key other than keycode 0x00 stayed
latched after a cancel.
Zero all four words so cancel_key_lock() releases every locked key, as
its name and its public declaration in process_key_lock.h imply.
The `get_last_record` signature was present in repeat_key.h but without
any implementation in repeat_key.c which caused compilation errors for
any user of `get_last_record`.
Jens van Almsick