QMK의 슬레이브 쪽에도 프로세스가 있어요.record 켜기()

좌우 분리형 키보드에서 버튼 누르기 이벤트 처리process_record()와 이로 인해 파생된 process_record_user() 등 함수는 보통 마스터 측에서만 실행된다.
보통 이래도 문제없지만 슬레이브 측도 OLED에서 버튼 이벤트와 관련된 표시를 하려고 하는 상황에서 곤란하다.투덜거려도 좋은 정보를 얻지 못하기 때문에 소스를 쫓아다니며 조사했다.

선결

정의SPLIT_TRANSPORT_MIRROR

overrideshould_process_keypress() 및 반환true

#define SPLIT_TRANSPORT_MIRROR

bool should_process_keypress(void) { return true; }

should_process_keypress()

트레이스process_record(), 획득tmk_core/common/keyboard.c의 키보드task()로 점화, 이 조건으로 사용should_process_keypress().
이 함수는 오버라이드도 할 수 있는데 댓글을 읽어보니 이번 용도였다.

/** \brief should_process_keypress
 *
 * Override this function if you have a condition where keypresses processing should change:
 *   - splits where the slave side needs to process for rgb/oled functionality
 */
__attribute__((weak)) bool should_process_keypress(void) { return is_keyboard_master();

기본적으로 위에서 말한 바와 같이 마스터만 사용하면 답장true이 가능하기 때문에 자주 답장true하면 이번 목적의 행동일 것이다.

SPLIT_TRANSPORT_MIRROR

그리고 이것도 정의가 필요하다.
일반적으로 TRS 케이블을 통해 slave에서 마스터 방향으로matrix scan의 키를 누르는 상태만 보냅니다.slave 방면에서 양손의 움직임을 파악하기 위해서는 반향적인 정보 전달이 필요하다. 이를 실현하는 것이 이 옵션이다.
https://docs.qmk.fm/#/feature_split_keyboard?id=communication-options
문헌에 따르면 마릭스 스칸의 연기에 다소 영향을 미친다고 쓰여 있지만 시도해 본 느낌, 특히 체감에는 영향을 미치지 않았다.응, 타자가 그렇게 빠르지 않아.

불순한 곳

이 두 동작은 거의 순조롭지만 슬레이브 측read_layer_state()의 결과는 이상하다.원래 도면층 키를 눌러도 반영되지 않고 다른 키에 반응한다.
하지만 이번 개인의 목적을 달성했으니 깊이 따지지 말고 여기서 끝내자.