* Move RGBLight animations to data driven, 0-9
* Move RGBLight animations to data driven, A
* Move RGBLight animations to data driven, B
* Move RGBLight animations to data driven, C
* Move RGBLight animations to data driven, D
* Move RGBLight animations to data driven, E
* Move RGBLight animations to data driven, F
* Move RGBLight animations to data driven, G
* Move RGBLight animations to data driven, H
* Move RGBLight animations to data driven, handwired
* Move RGBLight animations to data driven, I
* Move RGBLight animations to data driven, J
* Move RGBLight animations to data driven, K
* Move RGBLight animations to data driven, L
* Move RGBLight animations to data driven, M
* Move RGBLight animations to data driven, N
* Move RGBLight animations to data driven, O
* Move RGBLight animations to data driven, P
* Move RGBLight animations to data driven, Q
* Move RGBLight animations to data driven, R
* Move RGBLight animations to data driven, S
* Move RGBLight animations to data driven, T
* Move RGBLight animations to data driven, U
* Move RGBLight animations to data driven, V
* Move RGBLight animations to data driven, W
* Move RGBLight animations to data driven, X
* Move RGBLight animations to data driven, Y
* Move RGBLight animations to data driven, Z
* Fix incorrect placement
* Fix build failures and mismatches
Although `keychron/c2_pro/ansi/rgb` and `keychron/c2_pro/ansi/white` use
the same custom matrix code, the matrix layouts are slightly different;
in particular, only the `keychron/c2_pro/ansi/white` board actually uses
column 19. However, the handling of column 19 in the custom matrix code
was broken, therefore that column did not work.
Looks like the custom matrix code assumes that `SHIFT_COL_END` refers to
the last column connected to the shift register, and not to the column
past that; so the value of `SHIFT_COL_END` needs to be changed from 19
to 18 (columns 11...18 are connected to the shift register, and column
19 is connected to the C14 pin).
Also the code which was determining `SIZE_T` and `UNSELECT_ALL_COL` had
an off-by-one bug when counting the required number of bits (again due
to the confusion on the `SHIFT_COL_END` meaning); this had been fixed
too (the actual behavior of that part of the code did not change,
because both the old and the new version select the 8 bit variant).
Co-authored-by: Albert Y <76888457+filterpaper@users.noreply.github.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Drashna Jaelre <drashna@live.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: jack <0x6a73@protonmail.com>
Co-authored-by: Joel Challis <git@zvecr.com>
Co-authored-by: Joy <chang.li@westberrytech.com>
Co-authored-by: Joy Lee <joylee.lc@foxmail.com>
Keychron Q11 uses `matrix_mask` to mask away the matrix location used
for `SPLIT_HAND_MATRIX_GRID` (otherwise the keyboard will constantly
generate a wakeup request whenever the host enters suspend). However,
the value of `matrix_mask` is actually chosen to mask away all unused
locations, but it was apparently generated for the ANSI board and
therefore masks away the left Shift key on the ISO board, breaking the
functionality of that key.
Fix `matrix_mask` to make the masking work as intended:
- Set the `[4, 1]` bit to 1; this is the matrix location for the ISO
left Shift.
- Set the `[2, 5]` bit to 0; this is actually the matrix location which
corresponds to `#define SPLIT_HAND_MATRIX_GRID A2, A15` on the left
side, which was intended to be masked; apparently the wakeup problem
does not happen due to `SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT`, so the
left half actually has that matrix location open. On the right side
`A2, A15` is `[9, 6]`, which was masked off correctly.
The code for Helix rev3 boards could not be built with, e.g.,
`CONVERT_TO=rp2040_ce` due to invalid `#include <stdio.h>` in the
keyboard level `config.h` (apparently the AVR version of that file
contains guards against usage in assembly code, which was hiding the
bug). Move `#include <stdio.h>` to the C sources which need it.
